Developer Onboarding Guide

1. Welcome & Overview

Scope: This Developer Onboarding Guide covers 131 screens of the social-app React Native application. The screens assessed include, among others: Inbox (/messages/inbox), Shell (/search/shell), Feed (/src/view/com/feeds/feed), Conversation (/messages/conversation), Chat List (/messages/chat-list), Settings (/settings), Account Settings (/settings/account-settings), Profile Header Standard (/profile/header/profile-header-standard), Profile Header Labeler (/profile/header/profile-header-labeler), Explore (/search/explore), Starter Pack (/starter-pack), Hashtag (/hashtag), Topic (/topic), Saved Feeds (/saved-feeds), Login Form (/login/login-form), Signup State (/signup/state), Onboarding Layout (/onboarding/layout), Deactivated (/deactivated), Takendown (/takendown), Signup Queued (/signup-queued), and many more. Components, patterns, and features not included in the assessed documentation are outside the scope of this document. Because this assessment covers a large but not exhaustive portion of the application, some cross-cutting patterns may exist in unassessed screens.

Document disclosure: Generated by Inkwell Forge — automated codebase documentation analysis. Subject matter expert review is recommended before distribution.

What this application does: social-app is the official Bluesky mobile and web client, built on the AT Protocol (atproto) — a decentralized social networking protocol. It allows users to create accounts, compose and browse posts, follow other users, manage moderation preferences, participate in direct messaging, discover content through algorithmic and custom feeds, and configure their experience through a rich settings system. The primary users are Bluesky social network participants on iOS, Android, and web.

Tech stack at a glance:

How this guide is organized: Sections marked [Tutorial] walk you through an experience step by step. Sections marked [How-to] give you procedures for specific tasks. Sections marked [Reference] are lookup tables and factual descriptions. Sections marked [Explanation] provide context and rationale for architectural decisions.

Who to ask:

• [Team Lead: name] — overall architecture, onboarding questions
• [iOS Lead: name] — iOS-specific native modules, Reanimated, Expo
• [Android Lead: name] — Android-specific behavior, Gradle, native modules
• [Code Owner for AT Protocol integration: name] — @atproto/api, lexicon changes, PDS interactions
• [Code Owner for messaging: name] — /messages/* screens, chat event bus, polling
• [Code Owner for moderation: name] — labelers, moderation decisions, content filtering

2. Environment Setup [Tutorial]

This section takes you from a fresh machine to a running local development environment. Follow every step in order.

Step 1: Prerequisites — Core Toolchain

Node.js: Check the project's .nvmrc or package.json engines field for the required version.

# Install nvm if you don't have it, then:
nvm install   # reads .nvmrc automatically
nvm use
node --version

[Not documented — WHO: Team Lead; WHAT: What is the pinned Node.js version (check .nvmrc or package.json engines)?; WHERE: Replace nvm install with nvm install <version> above.]

Package manager: This project uses yarn as its package manager.

(inferred from Expo/React Native conventions and the presence of a yarn.lock — verify against the root package.json and any README in the repository)

npm install -g yarn
yarn --version

Git:

git --version  # must be installed

Step 2: Prerequisites — iOS Toolchain (macOS only)

Xcode: Install from the Mac App Store or developer.apple.com/xcode. Xcode 15+ is required for modern React Native.

xcode-select --version

Xcode Command Line Tools:

xcode-select --install

Ruby + CocoaPods: React Native iOS projects require CocoaPods. The project likely uses a .ruby-version file.

# Install rbenv (recommended)
brew install rbenv
rbenv install   # reads .ruby-version
rbenv global $(cat .ruby-version)

# Install bundler and pods
gem install bundler
bundle install

[Not documented — WHO: iOS Lead; WHAT: Does the project use bundle exec pod install (Bundler) or system pod install? Is there a .ruby-version file?; WHERE: Adjust the Ruby/CocoaPods setup commands above.]

Step 3: Prerequisites — Android Toolchain

Android Studio: Download from developer.android.com/studio.

Android SDK: Open Android Studio → SDK Manager → install the SDK platform version targeted by the app.

[Not documented — WHO: Android Lead; WHAT: What is the target Android SDK version (check android/build.gradle)?; WHERE: Add the specific SDK version to the Android Studio SDK Manager step above.]

JDK: React Native requires JDK 17 for modern builds.

# macOS with Homebrew:
brew install openjdk@17
export JAVA_HOME=$(/usr/libexec/java_home -v 17)

ANDROID_HOME environment variable: Add to your ~/.zshrc or ~/.bashrc:

export ANDROID_HOME=$HOME/Library/Android/sdk
export PATH=$PATH:$ANDROID_HOME/emulator
export PATH=$PATH:$ANDROID_HOME/platform-tools

Then reload your shell:

source ~/.zshrc

Android Emulator: In Android Studio → Device Manager → create a new AVD (e.g., Pixel 7, API 34).

Step 4: Expo / EAS CLI

This project uses Expo's bare workflow. Install the EAS CLI for builds and the Expo CLI for local development:

npm install -g eas-cli
npm install -g expo-cli   # or use npx expo directly
npx expo login            # authenticate with your Expo account

[Not documented — WHO: Team Lead; WHAT: What is the Expo organization name and which account credentials should new developers use?; WHERE: Add the org name to the npx expo login step above.]

Step 5: Clone and Install

git clone [repository-url]
cd [project-directory]
yarn install

iOS only — install CocoaPods:

cd ios && bundle exec pod install && cd ..

Step 6: Environment Configuration

The project uses environment variables for API endpoints, service URLs, and feature flags. These are likely loaded via a .env file and accessed through the #/env module.

cp .env.example .env

Open .env and fill in the required values:

[Not documented — WHO: Team Lead; WHAT: What are all required .env variables and their values for local development?; WHERE: Replace the placeholder rows in the table above with the actual variable names and descriptions.]

How environment variables are loaded: The #/env module exports platform-detection constants (IS_IOS, IS_ANDROID, IS_NATIVE, IS_WEB, IS_INTERNAL, IS_LIQUID_GLASS) and any build-time configuration. These are bundled at build time by Metro, not read at runtime from process.env in most cases.

Step 7: Expo Prebuild (Bare Workflow)

Because this project uses Expo's bare workflow with native code, you may need to run prebuild if the native directories are not committed:

npx expo prebuild --clean

When to re-run prebuild:

• After changing app.config.ts (bundle ID, app name, plugins)
• After adding a new native Expo module
• After changing native dependencies

[Not documented — WHO: iOS Lead or Android Lead; WHAT: Are the ios/ and android/ directories committed to the repository, or must expo prebuild be run on first clone?; WHERE: Clarify whether Step 7 is required on first setup or only after config changes.]

Step 8: Start the Development Server

# Start Metro bundler
yarn start
# or
npx expo start

# Launch on iOS Simulator
yarn ios
# or
npx expo run:ios

# Launch on Android Emulator
yarn android
# or
npx expo run:android

Step 9: Verify It Works

After launching, you should see the Bluesky splash screen followed by the login/signup flow. If you have a test account, log in and verify the home feed loads.

[Screenshot: first launch — Bluesky splash screen on iOS Simulator]

Confirm Metro is running: In the Metro terminal, you should see:

Metro waiting on exp://...

And after the app loads:

BUNDLE ./index.js

Step 10: Start Background Services

The messaging feature uses a polling-based event bus (useMessagesEventBus). No separate background service needs to be started manually — polling is managed in-process by the app when message screens are active.

[Not documented — WHO: Team Lead; WHAT: Are there any local mock servers, background workers, or additional services that need to be started for full local development (e.g., a local AT Protocol PDS)?; WHERE: Add any required startup commands here.]

3. Mobile Dev Setup [Tutorial]

Simulator & Emulator Selection

iOS Simulators:

# List available simulators
xcrun simctl list devices

# Boot a specific simulator
xcrun simctl boot "iPhone 15 Pro"

[Not documented — WHO: iOS Lead; WHAT: Which iOS Simulator model is the team's preferred target for development?; WHERE: Add the preferred simulator name to the xcrun simctl boot command above.]

Android Emulators:

# List available AVDs
emulator -list-avds

# Launch an AVD
emulator -avd [AVD_NAME]

Real device testing:

• iOS: Settings → Privacy & Security → Developer Mode → enable. Connect via USB, trust the computer in Xcode.
• Android: Settings → About Phone → tap Build Number 7 times → Developer Options → USB Debugging. Connect via USB.

# Verify Android device is connected
adb devices

Metro Bundler

# Start Metro
yarn start

# Clear Metro cache (use when you see module resolution errors)
yarn start --reset-cache
# or
npx expo start -c

# Metro runs on port 8081 by default. If there's a conflict:
yarn start --port 8088

In the Metro terminal:

• Press r — reload the app (JS only, no native rebuild)
• Press i — open iOS Simulator
• Press a — open Android Emulator
• Press ? — show all commands

Debugging

Flipper: If Flipper is configured, connect via the Flipper desktop app (fbflipper.com) for network inspection, React DevTools, and Redux/state inspection.

[Not documented — WHO: Team Lead; WHAT: Is Flipper configured for this project? If so, which plugins are used?; WHERE: Add Flipper plugin setup instructions here.]

Reactotron: If Reactotron is configured, start the Reactotron desktop app before launching the app.

[Not documented — WHO: Team Lead; WHAT: Is Reactotron configured for this project?; WHERE: Add Reactotron setup instructions here.]

React Native DevTools (Hermes): Shake the device or press Cmd+D (iOS Simulator) / Cmd+M (Android Emulator) → "Open Debugger". This opens Chrome DevTools for JS inspection.

Expo Dev Tools: Running npx expo start opens a browser-based panel with QR code, logs, and device management.

First-Run Troubleshooting

4. Codebase Orientation [Reference]

Directory Structure

src/
├── screens/             — Screen-level components organized by feature
│   ├── StarterPack/     — Starter Pack creation wizard
│   ├── Onboarding/      — Multi-step onboarding flow
│   ├── Settings/        — All settings screens
│   └── Search/          — Search and Explore screens
├── view/
│   └── com/             — Shared view components (legacy location)
│       ├── auth/        — Auth-related views (splash, login shell)
│       ├── feeds/       — Feed components
│       ├── lists/       — List member components
│       ├── posts/       — Post feed and post thread components
│       ├── profile/     — Profile-related components
│       ├── pager/       — Pager/tab components
│       └── util/        — Shared utility components (Error, EmptyState, etc.)
├── state/
│   ├── session/         — Authentication state, AT Protocol agent
│   ├── preferences/     — User preferences (persisted)
│   ├── queries/         — TanStack Query hooks for all data fetching
│   ├── shell/           — Global shell state (minimal mode, active convo)
│   ├── cache/           — Profile shadow cache, optimistic updates
│   └── service-config/  — Server-side feature flags
├── lib/
│   ├── constants.ts     — App-wide constants (DISCOVER_FEED_URI, etc.)
│   ├── routes/          — Navigation type definitions (CommonNavigatorParams)
│   ├── strings/         — String utilities (sanitizeHandle, cleanError, etc.)
│   ├── hooks/           — Shared custom hooks
│   └── media/           — Media picker utilities
├── components/          — Shared UI components (new design system location)
│   ├── Button.tsx
│   ├── Layout.tsx
│   ├── Link.tsx
│   ├── Typography.tsx
│   ├── forms/           — Toggle, TextField, Select components
│   ├── icons/           — SVG icon components
│   └── dialogs/         — Shared dialog components
├── navigation/          — Navigator definitions (inferred from route types)
├── locale/              — Lingui translation catalogs and language lists
├── analytics/           — Analytics abstraction (ax.metric, ax.logger)
├── features/
│   └── liveNow/         — Live streaming feature
├── alf/                 — Internal design system (atoms, theme, breakpoints)
│   ├── atoms.ts         — Atomic style tokens
│   ├── themes/          — Light, dim, dark theme definitions
│   └── tokens.ts        — Spacing, border radius, etc.
└── env.ts               — Platform detection constants (IS_IOS, IS_NATIVE, etc.)

modules/                 — Local Expo native modules
├── expo-bluesky-gif-view/    — Native GIF playback
├── expo-emoji-picker/        — Native emoji picker
├── expo-scroll-forwarder/    — Scroll event forwarding for iOS pager
└── expo-bluesky-swiss-army/  — Shared native utilities (SharedPrefs, etc.)

ios/                     — iOS native project (CocoaPods, Xcode workspace)
android/                 — Android native project (Gradle)
app.config.ts            — Expo app configuration (bundle ID, plugins, version)
metro.config.js          — Metro bundler configuration
babel.config.js          — Babel configuration (Lingui macros, path aliases)

Note: The src/view/com/ directory is a legacy location. New components are being added to src/components/ and src/screens/. When in doubt, ask your team lead which location to use for new work.

Key Files

Naming Conventions

5. Architecture & Key Decisions [Explanation]

React Native Framework Choice

What it is: This app uses Expo's bare workflow — Expo manages the native project configuration and provides a curated set of native modules, but the ios/ and android/ directories are fully committed and customizable.

Why it was chosen: The bare workflow gives the team access to custom native modules (the modules/ directory contains several first-party native modules like expo-bluesky-gif-view and expo-emoji-picker) while still benefiting from Expo's tooling (expo prebuild, EAS Build, OTA updates via expo-updates).

How it affects your work: You can use any React Native native module, but adding one requires running npx expo prebuild (or manually editing the native projects) and rebuilding the app. You cannot use Expo Go for development — you must use a development build.

Where to see it: app.config.ts, modules/ directory, ios/ and android/ directories.

Navigation System

What it is: React Navigation with native stack navigators and tab navigators. The canonical type map for all routes is CommonNavigatorParams and AllNavigatorParams in src/lib/routes/types.ts.

Why it was chosen: React Navigation is the standard for React Native apps. The native stack navigator provides native-feeling transitions on iOS and Android.

Navigator hierarchy (inferred from route types and screen documentation):

Root Navigator
├── Logged-out shell (auth flow)
│   ├── Splash
│   ├── Login Form
│   ├── Signup (multi-step wizard)
│   ├── Deactivated
│   ├── Takendown
│   └── Signup Queued
└── Authenticated shell
    ├── Main Tab Navigator
    │   ├── Home Tab (feed stack)
    │   ├── Search Tab (explore/search stack)
    │   ├── Notifications Tab
    │   ├── Messages Tab (chat list stack)
    │   └── Profile Tab
    └── Common Navigator (modal/push screens)
        ├── Profile screens
        ├── Post thread screens
        ├── Settings screens
        ├── Starter Pack screens
        ├── Onboarding flow
        └── ... (all other screens)

(inferred from CommonNavigatorParams, AllNavigatorParams, and screen documentation — verify the exact navigator structure against the navigation configuration files)

The ParamList type as the architectural contract: CommonNavigatorParams and AllNavigatorParams are the single source of truth for what screens exist and what parameters they accept. Every new screen must be registered here. TypeScript will catch navigation calls to unregistered screens at compile time.

How it affects your work: When you add a new screen, you must add it to the appropriate ParamList type before you can navigate to it. When you navigate to a screen, TypeScript enforces that you pass the correct parameters.

Where to see it: src/lib/routes/types.ts, any screen file that uses NativeStackScreenProps<CommonNavigatorParams, 'ScreenName'>.

State Management Strategy

What it is: A layered approach:

• Server state: TanStack Query (React Query v5) via hooks in src/state/queries/. All AT Protocol API data lives here.
• Session/auth state: Custom React context in src/state/session/. Provides currentAccount, accounts, and the AT Protocol agent.
• User preferences: Custom hooks in src/state/preferences/. Persisted to device storage.
• Global shell state: Custom context in src/state/shell/. Controls minimal shell mode, active starter pack, logged-out overlay, etc.
• Optimistic/shadow state: useProfileShadow in src/state/cache/ applies pending mutations to profile data before server confirmation.
• Wizard/flow state: useReducer-based state machines for multi-step flows (signup, onboarding, starter pack wizard).

Why it was chosen: TanStack Query handles the complexity of caching, deduplication, background refetching, and pagination for server data. Local state machines handle complex multi-step flows. This separation keeps components focused on rendering.

How it affects your work: When you need data from the Bluesky API, look for an existing query hook in src/state/queries/ before writing a new one. When you need to mutate data, use the corresponding mutation hook. Do not fetch() directly in components.

Where to see it: src/state/queries/post-feed.ts (feed queries), src/state/queries/profile.ts (profile queries), src/state/session/ (auth).

Data Fetching Pattern

What it is: TanStack Query infinite queries for paginated lists, regular queries for single resources, and mutations for writes. All queries are defined as custom hooks in src/state/queries/.

Why it was chosen: TanStack Query provides automatic caching, background refetching, deduplication, and optimistic update support without boilerplate.

Key patterns:

• Infinite queries: Used for feeds, follower lists, search results. fetchNextPage() is called from onEndReached in list components.
• Query key factories: FEED_RQKEY(feed), RQKEY_PROFILE(did), etc. — these are the cache keys. Use them for targeted invalidation.
• truncateAndInvalidate: A utility that truncates a feed's cached pages to the first page and marks it stale, used for pull-to-refresh and "load latest" behavior.
• staleTime: 0 default: Data is immediately considered stale. Background refetching happens on window focus and remount.

How it affects your work: Always use the existing query hooks. If you need a new endpoint, create a new hook in src/state/queries/. Use queryClient.invalidateQueries({ queryKey: RQKEY(...) }) to refresh data after mutations.

Where to see it: src/state/queries/post-feed.ts, src/state/queries/profile.ts, src/state/queries/actor-search.ts.

Authentication and Authorization Approach

What it is: AT Protocol session-based authentication. The agent (an AtpAgent instance from @atproto/api) carries the authenticated session token and is used for all API calls. Sessions are persisted to device storage and resumed on app launch.

Token storage: Session tokens are stored securely via the session state module. The accessJwt is used for API authentication.

Auth state propagation: useSession() provides currentAccount (the active account) and hasSession (boolean). The shell renders either the logged-out flow or the authenticated app based on session state.

Protected-route pattern: Screens that require authentication rely on the navigator's auth guard (not on per-screen checks). The useRequireAuth() hook wraps actions that require authentication — if the user is not logged in, it redirects to the sign-in flow before executing the action.

How it affects your work: Use useSession() to read auth state. Use useAgent() to get the AT Protocol agent for API calls. Use useRequireAuth() to gate user actions behind authentication. Do not store tokens in component state.

Where to see it: src/state/session/, src/lib/hooks/useRequireAuth.ts (inferred), any screen that calls useSession().

Platform Branching Strategy

What it is: Multiple mechanisms for handling iOS/Android/web differences:

1. Platform.OS conditionals: IS_IOS, IS_ANDROID, IS_NATIVE, IS_WEB constants from src/env.ts (which wrap Platform.OS).
2. platform() utility from #/alf: Returns different values for native vs. web — used in style definitions.
3. web() utility from #/alf: Applies styles only on web.
4. native() utility from #/alf: Applies styles only on native.
5. Platform-specific files: .ios.tsx, .android.tsx, .web.tsx — Metro resolves these automatically. Used for components with fundamentally different implementations (e.g., CaptchaWebView.web.tsx, StatusBarShadow.web.tsx).
6. IS_LIQUID_GLASS: A flag for the newer iOS design language variant.

Convention in this codebase: Use IS_NATIVE, IS_IOS, IS_ANDROID, IS_WEB constants (not Platform.OS directly) for consistency. Use .web.tsx file splits for components that are entirely different on web (e.g., web stubs that throw or return null).

How it affects your work: When writing platform-specific code, prefer the IS_* constants. For components that need fundamentally different implementations per platform, create platform-specific files. Check for existing .web.tsx stubs before assuming a component works on web.

Where to see it: src/env.ts, src/view/com/pager/draggable-scroll/DraggableScrollView.tsx (web-only drag scroll), src/signup/step-captcha/CaptchaWebView.web.tsx.

UI Component Strategy

What it is: A two-layer component system:

• New design system (src/components/, src/alf/): Button, Text, Layout, Link, Toggle, TextField, Select, Admonition, etc. These are the preferred components for new work.
• Legacy components (src/view/com/util/): Button, Text, Link, Toast, etc. — many are marked @deprecated. Use the new design system equivalents instead.

Design system atoms (#/alf): Atomic style tokens accessed as a.flex_1, a.px_xl, a.rounded_full, etc. These are the building blocks for all layout and typography.

Theme tokens: t.atoms.* (semantic, theme-aware) and t.palette.* (raw color values). Always use t.atoms.* for colors that should adapt to light/dark/dim themes.

How it affects your work: When building new UI, use components from src/components/ and atoms from #/alf. If you see a @deprecated import, replace it with the new equivalent. Do not add new components to src/view/com/util/.

Where to see it: src/components/Button.tsx, src/components/Layout.tsx, src/alf/atoms.ts.

Background and Async Processing Patterns

What it is: The messaging feature uses a polling-based event bus (useMessagesEventBus) rather than WebSockets. Screens that display messages request a poll interval when focused and active.

Feed polling: The home feed polls for new content every 60 seconds via setInterval in PostFeed. The Discover feed always reports hasNew = true when polled (algorithmic content is always fresh).

Optimistic updates: Profile follow/block mutations use a shadow cache (useProfileShadow) to reflect changes immediately. Like counts on labeler profiles are updated optimistically in local state.

Background sync: No service workers or background fetch are used. All data refresh is triggered by user interaction (pull-to-refresh, screen focus) or the polling intervals described above.

Where to see it: src/state/messages/ (inferred), src/view/com/posts/PostFeed.tsx, src/state/cache/profile-shadow.ts.

6. Development Patterns & Conventions [Reference + Explanation]

Pattern: Creating a New Screen

Type: Screen Pattern

When to use: Every time you add a new navigable screen to the app.

The pattern:

// 1. Register the route in src/lib/routes/types.ts
export type CommonNavigatorParams = {
  // ... existing routes ...
  MyNewScreen: { someParam: string; optionalParam?: number }
}

// 2. Create the screen component file
// src/screens/MyFeature/MyNewScreen.tsx
import React, { useCallback } from 'react'
import { View } from 'react-native'
import { NativeStackScreenProps } from '@react-navigation/native-stack'
import { useFocusEffect } from '@react-navigation/native'
import { Trans } from '@lingui/react/macro'

import { CommonNavigatorParams } from '#/lib/routes/types'
import { useSetMinimalShellMode } from '#/state/shell'
import { Layout } from '#/components/Layout'
import { Text } from '#/components/Typography'
import { atoms as a } from '#/alf'

type Props = NativeStackScreenProps<CommonNavigatorParams, 'MyNewScreen'>

export function MyNewScreen({ route }: Props) {
  const { someParam } = route.params
  const setMinimalShellMode = useSetMinimalShellMode()

  // Ensure full shell is visible when this screen is focused
  useFocusEffect(
    useCallback(() => {
      setMinimalShellMode(false)
    }, [setMinimalShellMode]),
  )

  return (
    <Layout.Screen testID="myNewScreen">
      <Layout.Header.Outer>
        <Layout.Header.BackButton />
        <Layout.Header.Content>
          <Layout.Header.TitleText>
            <Trans>My New Screen</Trans>
          </Layout.Header.TitleText>
        </Layout.Header.Content>
        <Layout.Header.Slot />
      </Layout.Header.Outer>
      <Layout.Content>
        {/* Screen content here */}
        <Text>{someParam}</Text>
      </Layout.Content>
    </Layout.Screen>
  )
}

// 3. Register the screen in the navigator definition
// (in the appropriate navigator file)

Key rules:

• Always add the route to CommonNavigatorParams (or AllNavigatorParams) before navigating to it.
• Always use Layout.Screen, Layout.Header.*, and Layout.Content for the standard shell.
• Always call setMinimalShellMode(false) on focus via useFocusEffect.
• Always use NativeStackScreenProps<CommonNavigatorParams, 'ScreenName'> for prop typing.
• All user-facing strings must be wrapped in <Trans> or _(msg\...`)`.

Example in the codebase: src/screens/Settings/AccountSettings.tsx, src/post/PostLikedBy.tsx.

Pattern: Adding a New API Call (Query Hook)

Type: Data Fetching Pattern

When to use: When you need to fetch data from the Bluesky AT Protocol API that doesn't already have a hook.

The pattern:

// src/state/queries/my-feature.ts
import { useQuery, useInfiniteQuery, useMutation } from '@tanstack/react-query'
import { useAgent } from '#/state/session'

// Query key factory — used for cache targeting and invalidation
export const RQKEY = (param: string) => ['my-feature', param]

// Regular query
export function useMyFeatureQuery(param: string) {
  const agent = useAgent()
  return useQuery({
    queryKey: RQKEY(param),
    queryFn: async () => {
      const res = await agent.app.bsky.someNamespace.someMethod({ param })
      return res.data
    },
  })
}

// Infinite (paginated) query
export function useMyFeatureInfiniteQuery(param: string) {
  const agent = useAgent()
  return useInfiniteQuery({
    queryKey: RQKEY(param),
    queryFn: async ({ pageParam }) => {
      const res = await agent.app.bsky.someNamespace.someMethod({
        param,
        cursor: pageParam,
        limit: 25,
      })
      return res.data
    },
    initialPageParam: undefined as string | undefined,
    getNextPageParam: lastPage => lastPage.cursor,
  })
}

// Mutation
export function useMyFeatureMutation() {
  const agent = useAgent()
  return useMutation({
    mutationFn: async (input: { id: string }) => {
      await agent.app.bsky.someNamespace.someAction(input)
    },
    onSuccess: () => {
      // Invalidate related queries
    },
  })
}

Key rules:

• Always define a RQKEY factory for cache targeting.
• Always use useAgent() to get the authenticated agent — never import the agent directly.
• Handle loading, error, and success states in the consuming component.
• Use useInfiniteQuery for paginated data; use useQuery for single resources.
• Invalidate related queries in onSuccess of mutations.

Example in the codebase: src/state/queries/post-feed.ts, src/state/queries/profile.ts, src/state/queries/actor-search.ts.

Pattern: Navigator Registration

Type: Navigation Pattern

When to use: When adding a new screen to an existing navigator.

The pattern:

// Step 1: Add to the ParamList type in src/lib/routes/types.ts
export type CommonNavigatorParams = {
  // ... existing routes ...
  MyNewScreen: { param: string }
}

// Step 2: Add to the navigator definition (in the appropriate navigator file)
// Example for a native stack navigator:
<Stack.Screen
  name="MyNewScreen"
  component={MyNewScreen}
  options={{ headerShown: false }}
/>

// Step 3: Navigate to it from another screen
navigation.navigate('MyNewScreen', { param: 'value' })

// Step 4: Use typed props in the screen component
type Props = NativeStackScreenProps<CommonNavigatorParams, 'MyNewScreen'>
export function MyNewScreen({ route, navigation }: Props) {
  const { param } = route.params
  // ...
}

Key rules:

• The route name in ParamList, the Stack.Screen name, and the navigation.navigate() call must all match exactly.
• TypeScript will catch mismatches at compile time.
• If you see the error "The action 'NAVIGATE' with payload was not handled by any navigator", the screen is not registered in the navigator.

Example in the codebase: src/lib/routes/types.ts (ParamList), any navigator definition file.

Pattern: Platform Branching

Type: Platform Pattern

When to use: When behavior or styling must differ between iOS, Android, and web.

The pattern:

import { IS_IOS, IS_ANDROID, IS_NATIVE, IS_WEB } from '#/env'
import { platform, web, native } from '#/alf'

// Style-level branching using alf utilities
const styles = {
  container: [
    a.flex_1,
    web({ maxWidth: 600 }),           // only on web
    native({ paddingBottom: 20 }),    // only on native
    platform({ ios: a.pt_xl, android: a.pt_md }),  // per-platform
  ],
}

// Logic-level branching using constants
if (IS_IOS) {
  // iOS-specific behavior
}

if (IS_NATIVE) {
  // Both iOS and Android
}

// Platform-specific file split (Metro resolves automatically):
// MyComponent.tsx        — default (native)
// MyComponent.web.tsx    — web only
// MyComponent.ios.tsx    — iOS only
// MyComponent.android.tsx — Android only

Key rules:

• Use IS_* constants from #/env, not Platform.OS directly.
• Use web(), native(), platform() from #/alf for style-level branching.
• Use .web.tsx / .ios.tsx / .android.tsx file splits for fundamentally different implementations.
• Web stubs that are not implemented should throw new Error('Not supported on web') or return null.

Example in the codebase: src/view/com/pager/DraggableScrollView.tsx + DraggableScrollView.web.tsx, src/profile/header/StatusBarShadow.tsx + StatusBarShadow.web.tsx.

Pattern: Form Handling and Validation

Type: Form Pattern

When to use: When collecting user input that requires validation before submission.

The pattern:

import { useState } from 'react'
import { useLingui } from '@lingui/react'
import { msg } from '@lingui/core/macro'
import { isOverMaxGraphemeCount } from '#/lib/strings/grapheme'
import { TextField } from '#/components/forms/TextField'
import { Button, ButtonText } from '#/components/Button'

export function MyForm() {
  const { _ } = useLingui()
  const [value, setValue] = useState('')
  const [isSubmitting, setIsSubmitting] = useState(false)

  const isTooLong = isOverMaxGraphemeCount({ text: value, maxCount: 50 })

  const onSubmit = async () => {
    if (!value || isTooLong) return
    setIsSubmitting(true)
    try {
      await someApiCall(value.trimEnd())
    } finally {
      setIsSubmitting(false)
    }
  }

  return (
    <>
      <TextField.Root isInvalid={isTooLong}>
        <TextField.LabelText>{_(msg`My Field`)}</TextField.LabelText>
        <TextField.Input
          value={value}
          onChangeText={setValue}
          label={_(msg`Enter a value`)}
        />
        <TextField.SuffixText
          label={`${value.length} out of 50`}>
          {value.length}/50
        </TextField.SuffixText>
      </TextField.Root>
      <Button
        label={_(msg`Submit`)}
        onPress={onSubmit}
        disabled={!value || isTooLong || isSubmitting}>
        <ButtonText>Submit</ButtonText>
      </Button>
    </>
  )
}

Key rules:

• Use isOverMaxGraphemeCount for character limits — it counts Unicode grapheme clusters, not raw characters.
• Always trimEnd() text values before submitting to the API.
• Disable the submit button during isSubmitting to prevent double-submission.
• All labels and hints must use Lingui's _(msg\...`)` pattern.
• Use TextField.Root isInvalid to visually indicate validation errors.

Example in the codebase: src/screens/Settings/AccountSettings.tsx (ChangeHandleDialog), src/login/SetNewPasswordForm.tsx.

Pattern: AsyncStorage Read/Write Lifecycle

Type: Data Fetching Pattern

When to use: When persisting user preferences or settings to device storage.

The pattern:

// Preferences are managed through the #/state/preferences layer.
// Do NOT access AsyncStorage directly in components.

// Reading preferences:
import { useLanguagePrefs } from '#/state/preferences'
const { appLanguage, contentLanguages } = useLanguagePrefs()

// Writing preferences:
import { useLanguagePrefsApi } from '#/state/preferences'
const setLangPrefs = useLanguagePrefsApi()
setLangPrefs.setAppLanguage('en')

// For search history and similar per-account storage:
import { useStorage } from '#/state/storage' // (inferred pattern)
const [history, setHistory] = useStorage(account, [did, 'searchTermHistory'])

Key rules:

• Never call AsyncStorage.getItem() or AsyncStorage.setItem() directly in components.
• All persistence goes through the #/state/preferences/ or #/state/storage abstraction layer.
• Preferences are hydrated on app startup; components can read them synchronously after hydration.
• The search screen uses useStorage(account, [did, 'searchTermHistory']) for per-account search history.

Example in the codebase: src/state/preferences/, src/screens/Search/SearchScreenShell.tsx (search history).

Pattern: Error Handling in Screen Components

Type: Screen Pattern

When to use: When a screen needs to display an error state from a failed API call.

The pattern:

import { ListMaybePlaceholder } from '#/view/com/util/List'
import { cleanError } from '#/lib/strings/errors'

export function MyScreen() {
  const { data, isLoading, isError, error, refetch } = useMyQuery()

  if (isLoading || isError || !data) {
    return (
      <ListMaybePlaceholder
        isLoading={isLoading}
        isError={isError}
        onRetry={refetch}
        errorMessage={cleanError(error)}
      />
    )
  }

  return <MyContent data={data} />
}

Key rules:

• Use cleanError(error) to sanitize raw error messages before displaying them to users.
• Use ListMaybePlaceholder for list screens — it handles loading, error, and empty states.
• Use Admonition type="error" for inline error messages within a form or settings screen.
• Always provide a retry mechanism (onRetry) when showing an error state.
• Log errors via logger.error(...) from #/logger, not console.error.

Example in the codebase: src/screens/Settings/ActivityNotificationSettings.tsx, src/notifications/ActivityList.tsx.

Pattern: Error Handling in Hook/Service Layer

Type: Data Fetching Pattern

When to use: When writing query hooks or mutation hooks that need to handle and report errors.

The pattern:

import { logger } from '#/logger'
import { useAnalytics } from '#/analytics'
import { cleanError } from '#/lib/strings/errors'
import { isNetworkError } from '#/lib/strings/errors'
import Toast from '#/view/com/util/Toast'

export function useMyMutation() {
  const { ax } = useAnalytics()
  return useMutation({
    mutationFn: async (input) => {
      await agent.someMethod(input)
    },
    onError: (e: any) => {
      if (isNetworkError(e)) {
        Toast.show('Check your internet connection', { type: 'error' })
      } else {
        logger.error('Failed to do the thing', { safeMessage: e.message })
        Toast.show(cleanError(e), { type: 'error' })
      }
    },
  })
}

Key rules:

• Use isNetworkError(e) to distinguish network failures from server errors.
• Use logger.error(message, { safeMessage: e.message }) — the safeMessage key avoids logging potentially sensitive raw error objects.
• Use cleanError(e) to produce user-safe error strings.
• Use Toast.show(...) for transient user-facing error notifications.
• Use ax.logger.error(...) for errors in analytics-instrumented code paths.

Example in the codebase: src/screens/StarterPack/StarterPackScreen.tsx (onFollowAll), src/profile/header/ProfileHeaderLabeler.tsx.

7. Common Development Tasks [How-to]

How to: Add a New Screen

When: You need to create a new navigable screen in the app.

Steps:

1. Add the route to the ParamList type in src/lib/routes/types.ts:

   export type CommonNavigatorParams = {
     // ... existing routes ...
     MyNewScreen: { param: string; optionalParam?: number }
   }

2. Create the screen component file (e.g., src/screens/MyFeature/MyNewScreen.tsx):

   import { NativeStackScreenProps } from '@react-navigation/native-stack'
   import { CommonNavigatorParams } from '#/lib/routes/types'
   // ... (see Screen Pattern in Section 6)

3. Register the screen in the navigator definition. Find the appropriate navigator file and add a Stack.Screen entry.

4. Navigate to the screen from another screen:

   navigation.navigate('MyNewScreen', { param: 'value' })

5. Test on both iOS Simulator and Android Emulator.

Watch out for: Forgetting to add the route to CommonNavigatorParams — you'll get a TypeScript error when trying to navigate. If you see "The action 'NAVIGATE' with payload was not handled by any navigator" at runtime, the screen is not registered in the navigator definition.

How to: Add a New Navigator

When: You need a new tab, stack, or drawer navigator for a new feature area.

Steps:

1. Create the navigator component file (e.g., src/navigation/MyFeatureNavigator.tsx).
2. Define the navigator using createNativeStackNavigator() or createBottomTabNavigator().
3. Add the navigator's screens to the appropriate ParamList type.
4. Nest the navigator inside the parent navigator.
5. Update AllNavigatorParams if the new navigator introduces new screen names.

Watch out for: Nested navigators can cause issues with the back button and deep linking. Test back navigation thoroughly on both platforms.

How to: Add a New API Endpoint / Hook

When: You need to call a Bluesky AT Protocol API endpoint that doesn't have an existing hook.

Steps:

1. Find the AT Protocol lexicon method in @atproto/api (e.g., agent.app.bsky.graph.getList).
2. Create a new hook file in src/state/queries/ (or add to an existing file if closely related).
3. Define a RQKEY factory for the query key.
4. Implement the hook using useQuery, useInfiniteQuery, or useMutation.
5. Export the hook and use it in your screen component.

Watch out for: Always use useAgent() to get the agent — never import it directly. Always handle the isLoading, isError, and data states in the consuming component.

How to: Add a New Form with Validation

When: You need to collect user input with validation before submitting to the API.

Steps:

1. Use useState for controlled inputs.
2. Use isOverMaxGraphemeCount for character limit validation.
3. Use TextField.Root, TextField.Input, TextField.LabelText from #/components/forms/TextField.
4. Disable the submit button when isSubmitting || isInvalid.
5. Call value.trimEnd() before submitting.
6. Handle errors with cleanError(e) and display via ErrorMessage or Admonition.

Watch out for: Using .length for character limits — this counts UTF-16 code units, not grapheme clusters. Emoji and some Unicode characters will be miscounted. Always use isOverMaxGraphemeCount.

How to: Handle Deep Links to a New Screen

When: You need a new screen to be reachable via a URL (e.g., bsky.app/profile/alice).

Steps:

1. Add the screen to the appropriate ParamList type.
2. Add a linking configuration entry in the app's linking config (inferred to be in the navigation setup file).
3. Test the deep link by opening the URL on a device.

[Not documented — WHO: Team Lead; WHAT: Where is the deep linking configuration defined (likely in the root navigator or app.config.ts)?; WHERE: Add the specific file path and configuration pattern here.]

How to: Run Tests

When: Before submitting a pull request or verifying a change.

Steps:

# Run unit tests
yarn test

# Run tests in watch mode
yarn test --watch

# Run a specific test file
yarn test src/state/queries/__tests__/utils.test.ts

(inferred from standard React Native/Expo project conventions — verify against package.json scripts)

Watch out for: The project uses Jest for unit tests. E2E tests (if configured) would use Detox or Maestro. Check package.json for the exact test scripts.

[Not documented — WHO: Team Lead; WHAT: What test frameworks are configured (Jest, Detox, Maestro)? What is the command to run E2E tests?; WHERE: Add the E2E test commands here.]

How to: Debug a Failing API Call

When: An API call is returning an error or unexpected data.

Steps:

1. Check the Metro terminal for any JavaScript errors.
2. Use Flipper's Network Inspector (if configured) to inspect the raw HTTP request and response.
3. Add a temporary console.log in the query function to log the response:

   const res = await agent.app.bsky.someMethod(params)
   console.log('API response:', JSON.stringify(res.data, null, 2))

4. Check the AT Protocol lexicon in @atproto/api to verify the expected request/response shape.
5. Verify the agent has a valid session by checking agent.session is not null.
6. Check cleanError(e) to see the user-facing error message.

Watch out for: AT Protocol errors often come as string messages in e.message rather than HTTP status codes. Use isNetworkError(e) to distinguish network failures from API errors.

How to: Add a New Native Package

When: You need to use a React Native library that has native code (iOS/Android).

Steps:

1. Install the package:

   yarn add react-native-some-package

2. If it's an Expo module, add it to app.config.ts plugins:

   plugins: [
     // ... existing plugins ...
     'react-native-some-package',
   ]

3. Run Expo prebuild to regenerate native code:

   npx expo prebuild --clean

4. Install CocoaPods (iOS):

   cd ios && bundle exec pod install && cd ..

5. Rebuild the app (a full native rebuild is required — r in Metro won't work):

   yarn ios   # or yarn android

Watch out for: After adding a native package, you must do a full native rebuild. Pressing r in Metro only reloads the JavaScript bundle — it does not rebuild native code. If you see "Native module X not found", you forgot to rebuild.

How to: Handle a Platform-Specific Difference

When: A feature behaves differently on iOS vs. Android vs. web.

Steps:

1. For style differences: Use platform(), web(), or native() from #/alf:

   style={[a.flex_1, web({ maxWidth: 600 }), platform({ ios: a.pt_xl, android: a.pt_md })]}

2. For logic differences: Use IS_IOS, IS_ANDROID, IS_NATIVE, IS_WEB from #/env:

   if (IS_IOS) { /* iOS-specific behavior */ }

3. For fundamentally different implementations: Create platform-specific files:

   • MyComponent.tsx — default (native)
   • MyComponent.web.tsx — web only

4. Test on both platforms before submitting.

Watch out for: The .web.tsx file split is resolved by Metro at build time. If you create MyComponent.web.tsx, Metro will use it for web builds and MyComponent.tsx for native builds. Make sure both files export the same interface.

8. Debugging & Troubleshooting [How-to]

Common Error: Metro Module Resolution Failure

Symptoms: Red screen with "Unable to resolve module X from Y" or "Module not found".

Cause: A native package was added but not linked, or node_modules is out of sync after a git pull.

Fix:

1. yarn install — reinstall all packages.
2. cd ios && bundle exec pod install && cd .. — reinstall iOS pods.
3. yarn start --reset-cache — clear Metro's module cache.
4. If still failing, do a full native rebuild: yarn ios or yarn android.

Common Error: iOS Build Failure (CocoaPods)

Symptoms: Xcode build fails with "No such module" or "Unable to find a specification for...".

Cause: CocoaPods cache is stale, or a new native dependency was added without running pod install.

Fix:

1. cd ios && bundle exec pod install && cd ..
2. If that fails: pod repo update && bundle exec pod install
3. If still failing: cd ios && bundle exec pod install --repo-update && cd ..
4. Clean Xcode build folder: Xcode → Product → Clean Build Folder, then rebuild.

Common Error: Android Build Failure (Gradle)

Symptoms: Gradle build failed with errors about SDK version, JDK, or NDK.

Cause: ANDROID_HOME or JAVA_HOME not set correctly, or wrong SDK/JDK version.

Fix:

1. Verify ANDROID_HOME points to your Android SDK: echo $ANDROID_HOME
2. Verify JAVA_HOME points to JDK 17: echo $JAVA_HOME
3. Check android/build.gradle for the required compileSdkVersion and targetSdkVersion.
4. Install the required SDK version via Android Studio → SDK Manager.
5. Try: cd android && ./gradlew clean && cd .., then rebuild.

Common Error: Navigation Error — Screen Not Handled

Symptoms: "The action 'NAVIGATE' with payload {name: 'MyScreen', params: {...}} was not handled by any navigator."

Cause: The screen is registered in CommonNavigatorParams (TypeScript type) but not in the actual navigator definition (the Stack.Screen component).

Fix:

1. Find the navigator that should contain your screen.
2. Add <Stack.Screen name="MyScreen" component={MyScreen} /> to that navigator.
3. Verify the name prop exactly matches the key in CommonNavigatorParams.

Common Error: Platform-Specific Crash

Symptoms: App crashes on iOS but not Android (or vice versa), or behavior is different between platforms.

Cause: Platform-specific API usage, missing Platform.OS check, or a native module that behaves differently.

Fix:

1. Check if the code uses any iOS-only or Android-only APIs without a platform guard.
2. Add IS_IOS / IS_ANDROID guards from #/env.
3. Check if there's a .ios.tsx or .android.tsx file that should be created.
4. Test on both platforms before submitting.

Common Error: AsyncStorage Hydration Race Condition

Symptoms: Preferences or settings appear as default values on first render, then "jump" to the correct values after a brief delay.

Cause: The preferences state is loaded asynchronously from storage. Components that read preferences before hydration completes see default values.

Fix:

1. Check if the preference hook returns undefined during loading (e.g., langPrefs.appLanguage may be undefined before hydration).
2. Add a loading guard: if (!preferences) return <Loader />
3. Use ?? defaultValue to provide safe fallbacks.
4. Do not store preferences in local useState — always read from the preference hooks.

Common Error: Deep Link Not Opening Correct Screen

Symptoms: Tapping a deep link opens the app but navigates to the wrong screen or shows an error.

Cause: The linking configuration prefix doesn't match the URL, or the screen is not registered in the linking config.

Fix:

1. Check the linking configuration (inferred to be in the navigation setup or app.config.ts).
2. Verify the URL prefix matches the app's scheme.
3. Verify the screen name in the linking config matches the CommonNavigatorParams key exactly.
4. Test with npx uri-scheme open "bsky://..." --ios or adb shell am start -a android.intent.action.VIEW -d "bsky://...".

[Not documented — WHO: Team Lead; WHAT: Where is the deep linking configuration defined and what is the URL scheme?; WHERE: Add the specific file path and URL scheme here.]

Common Error: expo prebuild Generates Unexpected Native Code

Symptoms: After running expo prebuild, the ios/ or android/ directories have unexpected changes.

Cause: app.config.ts or a plugin configuration changed, causing prebuild to regenerate native code differently.

Fix:

1. Review the changes in ios/ and android/ to understand what changed.
2. If the changes are expected (you added a plugin), commit them.
3. If the changes are unexpected, check app.config.ts for unintended modifications.
4. Run npx expo prebuild --clean to start fresh from the current config.

9. Gotchas & Pitfalls [Reference]

10. First-Task Checklist [Tutorial]

This tutorial walks you through adding a new informational screen reachable from the Settings section. It exercises the most common development patterns: ParamList registration, navigator update, screen component structure, data fetching, and cross-platform testing.

The Task

Add a new "App Info" screen that displays the app version, build date, and a link to the Bluesky status page. It should be reachable from the main Settings screen.

What You'll Learn

• Registering a route in CommonNavigatorParams
• Adding a screen to the Settings navigator
• Creating a screen component with the standard shell
• Reading a constant value (no API call needed for this task)
• Using Layout.* components
• Testing on both iOS and Android

Step 1: Register the Route

Open src/lib/routes/types.ts and add your new screen to CommonNavigatorParams:

export type CommonNavigatorParams = {
  // ... existing routes ...
  AppInfo: undefined  // no params needed
}

Expected result: TypeScript now knows about 'AppInfo' as a valid route name. You can navigate to it (though it will fail at runtime until you complete the next steps).

Step 2: Create the Screen Component

Create src/screens/Settings/AppInfoScreen.tsx:

import React, { useCallback } from 'react'
import { View } from 'react-native'
import { NativeStackScreenProps } from '@react-navigation/native-stack'
import { useFocusEffect } from '@react-navigation/native'
import { Trans } from '@lingui/react/macro'

import { CommonNavigatorParams } from '#/lib/routes/types'
import { useSetMinimalShellMode } from '#/state/shell'
import { Layout } from '#/components/Layout'
import { Text } from '#/components/Typography'
import { atoms as a } from '#/alf'
import { STATUS_PAGE_URL } from '#/lib/constants'
import { InlineLinkText } from '#/components/Link'

type Props = NativeStackScreenProps<CommonNavigatorParams, 'AppInfo'>

export function AppInfoScreen({}: Props) {
  const setMinimalShellMode = useSetMinimalShellMode()

  useFocusEffect(
    useCallback(() => {
      setMinimalShellMode(false)
    }, [setMinimalShellMode]),
  )

  return (
    <Layout.Screen testID="appInfoScreen">
      <Layout.Header.Outer>
        <Layout.Header.BackButton />
        <Layout.Header.Content>
          <Layout.Header.TitleText>
            <Trans>App Info</Trans>
          </Layout.Header.TitleText>
        </Layout.Header.Content>
        <Layout.Header.Slot />
      </Layout.Header.Outer>
      <Layout.Content>
        <View style={[a.px_xl, a.py_lg, a.gap_md]}>
          <Text style={[a.text_md]}>
            <Trans>Status page:</Trans>{' '}
            <InlineLinkText to={STATUS_PAGE_URL} label="Bluesky status page">
              {STATUS_PAGE_URL}
            </InlineLinkText>
          </Text>
        </View>
      </Layout.Content>
    </Layout.Screen>
  )
}

Expected result: The screen component exists and compiles without errors.

Step 3: Add the Screen to the Navigator

Find the Settings navigator definition file. Add your screen:

import { AppInfoScreen } from '#/screens/Settings/AppInfoScreen'

// Inside the navigator:
<Stack.Screen name="AppInfo" component={AppInfoScreen} />

[Not documented — WHO: Team Lead; WHAT: Which file contains the Settings navigator definition?; WHERE: Replace this step with the specific file path.]

Expected result: The navigator now knows how to render AppInfoScreen when 'AppInfo' is navigated to.

Step 4: Add a Link from the Settings Screen

In the main Settings screen (likely src/screens/Settings/index.tsx or similar), add a link to your new screen:

import { useNavigation } from '@react-navigation/native'

// Inside the component:
const navigation = useNavigation()

// In the JSX:
<SettingsList.LinkItem
  to={{ screen: 'AppInfo' }}
  label={_(msg`App Info`)}>
  <SettingsList.ItemText>
    <Trans>App Info</Trans>
  </SettingsList.ItemText>
</SettingsList.LinkItem>

[Not documented — WHO: Team Lead; WHAT: Which file is the main Settings screen and where should the new link be added?; WHERE: Replace this step with the specific file path and location within the settings list.]

Step 5: Test on Both Platforms

iOS Simulator:

1. Run yarn ios (or press i in Metro if already running).
2. Navigate to Settings.
3. Tap "App Info".
4. Verify the screen renders with the correct title and status page link.

Android Emulator:

1. Run yarn android (or press a in Metro if already running).
2. Repeat the same navigation steps.
3. Verify the screen renders identically.

[Screenshot: AppInfo screen on iOS Simulator showing the status page link]

Verification

Your task is complete when:

• CommonNavigatorParams includes AppInfo: undefined
• AppInfoScreen.tsx exists and renders without errors
• The screen is registered in the Settings navigator
• A link to the screen exists in the Settings list
• The screen renders correctly on iOS Simulator
• The screen renders correctly on Android Emulator
• The back button returns to the Settings screen
• All strings are wrapped in <Trans> or _(msg\...`)`

What to Do Next

Once you've completed this task, try these more complex exercises:

1. Add a data-fetching hook: Modify AppInfoScreen to fetch the current app version from a query hook instead of a constant.
2. Add a setting toggle: Add a new boolean preference to the Settings screen using Toggle.Item and usePreferencesQuery.
3. Add a new tab: Create a new tab in the main tab navigator with its own stack of screens.

11. Glossary

Technologies

Patterns & Conventions

Domain Terms