A mid-level course for developers who can already build a React Native app and want to ship and maintain one professionally. The first module covers app architecture (screens, state and services), caching API data with offline fallbacks, and secure authentication on a public client: tokens in the Keychain and Keystore, refresh flows and OAuth with PKCE. The second module covers quality: unit, component and end-to-end tests with Jest, React Native Testing Library and Maestro or Detox; profiling and fixing slow lists; and testing with VoiceOver and TalkBack. The last module covers releases: store listings, signing, privacy declarations and review; build profiles, crash reporting and over-the-air updates; and deciding when a native module is worth it. Every lesson has a reading, free videos and a quiz, and most have hands-on steps on your own computer and phone using free tiers. Publishing to the stores needs paid developer accounts (Apple $99 per year, Google Play $25 one-off; checked on 2026-10-23), but every exercise can be finished without paying. Prerequisites: Mobile Development Basics and Back-End Web APIs.

Take a React Native app to production: architecture, offline data, secure auth, testing, performance, accessibility and store releases.

Mobile App Production

## Why it matters

A course project can live in one big screen file. A production app cannot: it grows to dozens of screens, several developers, offline data, sign-in and analytics, and it must keep shipping for years. Without structure, every change touches everything and every bug is hard to find. Architecture is simply deciding **where each kind of code lives** so that changes stay small and parts can be tested on their own.

## Three layers that work for most apps

1. **Screens (UI).** Components that render and handle user input. They read state and call actions; they do not know URLs, tokens or storage keys.
2. **State.** What the app currently knows: the signed-in user, the cart, cached server data, form drafts. It changes only through clear actions (reducer actions, store methods or query mutations).
3. **Services.** Code that talks to the outside world: the HTTP API client, storage, push notifications, analytics, device APIs. Each service has a small interface, such as `api.getOrders()` or `storage.load(key)`.

Data flows one way: a screen triggers an action, the action calls a service, the service result updates state, and the screen re-renders from state.

```text
Screen --(action)--> State logic --(call)--> Service --(HTTP/storage)--> world
  ^                       |
  +------(re-render)------+
```

## A folder layout

There is no single correct layout, but grouping by **feature** scales better than grouping by file type once an app is large:

```text
app/                    # Expo Router screens (thin: compose feature components)
  (tabs)/orders.tsx
  orders/[id].tsx
src/
  features/
    orders/
      OrderList.tsx     # UI
      useOrders.ts      # state + data hook
      ordersApi.ts      # service calls for this feature
      orders.test.ts
    auth/
      ...
  services/
    apiClient.ts        # base URL, auth header, retries, error mapping
    storage.ts
  ui/                   # shared design-system components (Button, Card)
```

Screens in `app/` stay thin: they read route params and render feature components. Anything shared lives in `services/` or `ui/`. A feature can be deleted by deleting its folder.

## Server state versus client state

The most useful distinction in modern apps is between:

- **Server state**: data the server owns (orders, profiles, posts). It can be stale, needs caching, refetching and offline handling. Libraries such as **TanStack Query** (React Query) manage it: caching by key, background refresh, retries and loading flags.
- **Client state**: data only the app owns (selected tab, a draft, UI toggles, the current theme). Keep it in `useState`, a reducer, context or a small store such as Zustand.

Mixing them causes bugs: copying server data into a global store means you now have two sources of truth that drift apart. Let a query cache hold server data and keep the global store small.

## Worked example: a thin screen

```javascript
// src/features/orders/ordersApi.ts
export function makeOrdersApi(client) {
  return {
    list: () => client.get("/orders"),
    get: (id) => client.get(`/orders/${id}`),
  };
}

// src/features/orders/useOrders.ts
export function useOrders() {
  return useQuery({ queryKey: ["orders"], queryFn: () => ordersApi.list() });
}

// app/(tabs)/orders.tsx
export default function OrdersScreen() {
  const { data, isLoading, error, refetch } = useOrders();
  if (isLoading) return <Spinner />;
  if (error) return <ErrorState onRetry={refetch} />;
  return <OrderList orders={data} />;
}
```

The screen knows nothing about URLs or tokens. The API module receives its client as an argument (**dependency injection**), so a test can pass a fake client that returns canned data. When the base URL or auth scheme changes, you edit one file.

## Common mistakes

- **Fetching inside every component.** The same request runs five times and loading states disagree. Centralize data access in hooks or a query cache.
- **A giant global store holding server data.** It goes stale; prefer a query cache for server data.
- **Business rules in JSX.** Price calculations or validation buried in a component cannot be unit-tested. Move them to plain functions.
- **Services that import screens.** Dependencies should point inward toward services and pure logic, never from services back to UI.
- **Over-engineering on day one.** Start with features and a shared API client; add layers when the pain appears.

## Quick recap

- Separate screens (UI), state (what the app knows) and services (talking to the world).
- Group code by feature; keep route files thin.
- Treat server state and client state differently; a query cache is a good home for server data.
- Pass dependencies in, so each layer can be tested with fakes.

## Try it

Take the quiz in the Do tab, then sketch the folders for an app you would like to build.


Separate screens, state and services so a growing app stays easy to change and test.

Structuring a mobile app

How to Architect a Scalable React Native App (Best Practices)

## Why it matters

Users open an app expecting to see something immediately, whether they are on fast Wi-Fi, a weak signal or in airplane mode. If every screen waits for the network, the app feels slow online and useless offline. A good caching strategy shows the last known data at once, refreshes it in the background, and is honest when data might be out of date.

## Caching strategies

- **Network first:** try the network; fall back to cache only if it fails. Always fresh when online, but every screen waits.
- **Cache first:** use the cache if present; hit the network only when there is nothing cached. Fast, but data can go stale forever.
- **Stale-while-revalidate:** show cached data immediately, then fetch and update. This is the default in TanStack Query and works for most screens.
- **Time-to-live (TTL):** a cached entry is "fresh" for a set time (say 5 minutes). Fresh entries are used without a request; older ones trigger a refresh, but can still be shown if the refresh fails.

Pick per screen. A product catalog can be minutes stale; an account balance should be refreshed every time and labelled with its "last updated" time.

## Worked example: read-through cache with offline fallback

Each cache entry stores the data and when it was saved:

```javascript
// cache: { [key]: { data, savedAt } }
function readThrough(cache, key, now, ttlMs, fetchFn) {
  const entry = cache[key];
  if (entry && now - entry.savedAt < ttlMs) {
    return { data: entry.data, source: "cache", cache };          // fresh: no request
  }
  const result = fetchFn();                                        // { ok, data }
  if (result.ok) {
    return { data: result.data, source: "network",
             cache: { ...cache, [key]: { data: result.data, savedAt: now } } };
  }
  if (entry) return { data: entry.data, source: "stale", cache };  // offline fallback
  return { data: null, source: "error", cache };
}
```

The `source` tells the UI what to say: nothing for `cache` or `network`, a small "Showing saved data from 10:42" banner for `stale`, and an error state with a retry button for `error`. Passing `now` in, instead of calling `Date.now()` inside, makes the function easy to test.

In a real app the fetch is asynchronous and the cache is persisted (AsyncStorage, MMKV or SQLite) so it survives restarts. TanStack Query can persist its cache with a persister plugin and pause requests while offline, using NetInfo through its `onlineManager`.

## Writes and sync

Reads are the easy half. For writes:

- **Optimistic updates:** update the cached data immediately, send the request, and roll back if it fails. TanStack Query's `onMutate` / `onError` support this.
- **Outbox queue:** if offline, store the change and send it later, in order (you built one in Mobile Development Basics).
- **Conflicts:** if two devices edit the same record, someone has to win. Common rules are last-write-wins with a server timestamp, or a version number that makes the server reject stale writes (HTTP 409) so the app can ask the user.
- **Sync engines:** for data-heavy offline apps, libraries such as WatermelonDB or PowerSync keep a local database in sync with the server. They are worth it when offline is the main use case, not for a few cached lists.

## Invalidation

"There are only two hard things in computer science: cache invalidation and naming things." In practice:

- after a mutation, invalidate the affected keys (`queryClient.invalidateQueries({ queryKey: ["orders"] })`),
- refetch when the app returns to the foreground or the network reconnects,
- include the user id in cache keys, and **clear the cache on sign-out** so the next person on a shared device does not see someone else's data.

## Common mistakes

- No TTL, so the cache is used forever and users never see new data.
- Throwing away cached data when a refresh fails, leaving a blank screen offline.
- Hiding staleness: a balance from yesterday shown as if it were current.
- Forgetting to clear user data on sign-out.
- Caching everything; some data (one-time codes, payment status) must always be fetched.

## Quick recap

- Choose a strategy per screen; stale-while-revalidate with a TTL suits most.
- On failure, fall back to cached data and say that it is saved data.
- Invalidate after writes, refetch on reconnect and clear the cache on sign-out.

## Try it

In the Do tab you will write `readThrough` and `isFresh`, the core of a cache with offline fallback, and test them with a fake fetch.


Cache API data with a time-to-live, fall back to saved data offline, and invalidate it correctly.

Data sync and caching

React Query in 100 Seconds

Karan Balodi – Offline-First React Native: Designing for production | App.js Conf 2026

## Why it matters

Almost every production app has accounts, and the mobile side of authentication is where many security mistakes happen. A phone can be lost, stolen, backed up, or rooted, and your app's code is in the user's hands, so anyone can unpack it and read it. Mobile auth has to assume all of that.

## What is different from the web

- **No httpOnly cookies by default.** Web apps can keep a session in a cookie the JavaScript cannot read. Mobile apps usually hold tokens themselves and send them in an `Authorization: Bearer <token>` header, so where you store the token matters.
- **Your bundle is public.** Anything in your JavaScript (API keys, client secrets) can be extracted from the app package. Treat the app as a **public client**: it can hold no secret.
- **Long sessions.** Users expect to stay signed in for weeks, so apps pair a short-lived access token with a longer-lived refresh token.
- **Biometrics** (Face ID, fingerprint) can unlock a stored credential locally, but they are not a login by themselves.

## Storing tokens securely

Use the platform's secure storage:

- **iOS Keychain** and **Android Keystore**-backed encrypted storage. In Expo, `expo-secure-store` wraps both. In bare React Native, `react-native-keychain` is common.
- **Not** AsyncStorage, plain files, or Redux persisted to disk: those are unencrypted and can end up in backups.
- Keep tokens in memory while the app runs and read them from secure storage at startup.

```javascript
import * as SecureStore from "expo-secure-store";

export async function saveSession({ accessToken, refreshToken }) {
  await SecureStore.setItemAsync("refreshToken", refreshToken);
  memory.accessToken = accessToken;     // short-lived; memory is enough
}

export async function clearSession() {
  await SecureStore.deleteItemAsync("refreshToken");
  memory.accessToken = null;
}
```

SecureStore is meant for small values (a few kilobytes), which fits tokens.

## Access and refresh tokens

A typical flow:

1. The user signs in. The server returns an **access token** (valid for minutes) and a **refresh token** (valid for days or weeks).
2. Every API call sends the access token.
3. When the server answers **401**, the API client calls the refresh endpoint once, stores the new tokens, and retries the original request.
4. If refreshing fails, the session is over: clear storage, clear caches, and send the user to sign-in.

Two details matter in production. If five requests fail with 401 at the same moment, only **one** refresh should run and the others should wait for it (share a single pending promise). And servers should **rotate** refresh tokens (issue a new one on each refresh and revoke the old one), so a stolen token stops working quickly.

## Signing in with another provider

For "Sign in with Google/Apple" or your company's identity provider, use **OAuth 2.0 with PKCE** (Proof Key for Code Exchange) in the system browser, for example with `expo-auth-session` or the providers' native SDKs. PKCE exists precisely because mobile apps cannot keep a client secret. Never ask for the user's Google password in your own form, and never embed a client secret in the app. Apple's guidelines require apps that offer certain third-party sign-in options to also offer an equivalent privacy-focused option such as Sign in with Apple; read the current App Review Guidelines before you ship (checked on 2026-10-23).

## Biometrics

`expo-local-authentication` asks the OS to verify Face ID or a fingerprint and returns success or failure. Use it to **gate access** to a credential already on the device ("Unlock with Face ID"), with a fallback to the device passcode or a password. The server never sees the fingerprint.

## Common mistakes

- Tokens in AsyncStorage.
- API secrets or admin keys in the app bundle. Put privileged calls on your server.
- Logging tokens or full request headers to the console or a crash reporter.
- Refresh storms: many parallel refresh calls that invalidate each other.
- Sign-out that clears the token but leaves cached personal data on screen.
- Building your own password reset or 2FA from scratch when the backend already has a secure flow; the app should call the backend's endpoints.

## Quick recap

- Mobile apps are public clients: no secrets in the bundle.
- Store refresh tokens in the Keychain/Keystore (expo-secure-store), keep access tokens short-lived.
- On 401, refresh once, share the pending refresh, retry, and sign out cleanly if it fails.
- Use OAuth with PKCE in the system browser for third-party sign-in; biometrics unlock local credentials.

## Try it

Take the quiz in the Do tab. Then look at the auth endpoints you built in Back-End Web APIs and decide which token each would return to a mobile client.


Store tokens securely, refresh sessions safely and use OAuth with PKCE on a public client.

Auth on mobile

Where to store JWT tokens and Session Ids on React Native

Building an Auth Flow with Expo Router

Structure screens, state and services; cache data with offline fallbacks; handle auth securely.

App Architecture

In your Expo project run `npx expo install jest-expo jest @testing-library/react-native --dev`, add `"jest": { "preset": "jest-expo" }` and a `test` script to `package.json`.

Write a unit test for one pure function from your app (a reducer or formatter) and run `npm test`.

Write a component test with `render`, `screen.getByRole` and `fireEvent.press` for a component that changes state when tapped.

Add a test for a loading or error state by passing a fake API or mocking the module, using `findByText` for content that appears later.

Break the component on purpose (change the label), run the tests, read the failure, then fix it.

Optional: install the Maestro CLI from maestro.dev, start an Android emulator (or iOS Simulator on a Mac) with your app running, write a 3-line flow and run `maestro test <file>.yaml`.

Add `npm test` to your project's README or CI so it runs on every change.

## Why it matters

Mobile releases are slow to undo. A web bug can be fixed in minutes; a broken mobile build may sit in users' hands until store review approves the fix and every user updates. Automated tests catch regressions before that happens and let a team change code with confidence. Mid-level mobile developers are expected to write them as a normal part of every feature.

## The testing pyramid for mobile

- **Unit tests** (many, fast): plain functions and reducers. Price rules, validation, the navigation and cache logic you wrote earlier. Run with **Jest**.
- **Component tests** (a good number): render one component or screen in a simulated environment and interact with it like a user. Use **React Native Testing Library** (RNTL) with Jest.
- **End-to-end (e2e) tests** (a few, slow): drive the real app on a simulator, emulator or device, for the journeys that must never break (sign in, checkout). Use **Maestro** (flows written in YAML) or **Detox** (tests written in JavaScript, synchronised with the app).
- **Manual testing** on real devices for what automation misses: feel, gestures, small screens, slow phones.

## Setting up Jest in Expo

```bash
npx expo install jest-expo jest @testing-library/react-native --dev
```

Add to `package.json`:

```json
{
  "scripts": { "test": "jest --watchAll=false" },
  "jest": { "preset": "jest-expo" }
}
```

The `jest-expo` preset mocks native modules so components render in Node without a phone.

## Worked example: a component test

The component:

```javascript
export function Counter({ initial = 0 }) {
  const [count, setCount] = useState(initial);
  return (
    <View>
      <Text>Count: {count}</Text>
      <Pressable accessibilityRole="button" onPress={() => setCount(count + 1)}>
        <Text>Add one</Text>
      </Pressable>
    </View>
  );
}
```

The test, written the way a user would interact:

```javascript
import { render, screen, fireEvent } from "@testing-library/react-native";
import { Counter } from "./Counter";

test("adds one when the button is pressed", () => {
  render(<Counter initial={2} />);
  fireEvent.press(screen.getByRole("button", { name: "Add one" }));
  expect(screen.getByText("Count: 3")).toBeOnTheScreen();
});
```

The query `getByRole("button", { name: ... })` finds the element by its accessibility role and label, so the test also checks that the button is accessible. Prefer role and text queries over test ids; reach for `testID` only when nothing user-visible identifies an element. Recent versions of RNTL include the `toBeOnTheScreen` matcher; older setups need `@testing-library/jest-native`.

For screens that fetch data, inject a fake API (from the architecture lesson) or mock the module, and use `findByText` (which waits) for content that appears after loading.

## Worked example: an e2e flow with Maestro

Maestro drives the app through the accessibility tree. A flow is a YAML file:

```yaml
appId: com.yourname.studytimer
---
- launchApp
- tapOn: "Add one"
- assertVisible: "Count: 1"
```

Run it with `maestro test flows/counter.yaml` against a running Android emulator or iOS Simulator (Maestro's CLI runs on macOS, Linux and Windows; the iOS Simulator needs a Mac). Detox does the same job with JavaScript tests and waits automatically for animations and network calls to settle, at the cost of a more involved setup. EAS can run e2e tests on its build servers as part of a build.

## What to test

- Every reducer and pure function: unit tests.
- Every screen's main states: loading, data, empty, error.
- Interactions that change state: taps, typing, toggles.
- One or two e2e journeys per critical flow.
- Bugs: write a failing test that reproduces each fixed bug, so it stays fixed.

## Common mistakes

- Testing implementation details (state variable names, internal functions) so tests break on every refactor. Test what the user sees.
- Snapshot tests of whole screens that everyone updates without reading.
- Real network calls in unit or component tests: slow and flaky. Mock or inject.
- Too many e2e tests: they are slow and brittle. Keep them for critical paths.
- Timing-based waits (`sleep(2000)`). Use `findBy...` queries or the e2e tool's built-in waiting.

## Quick recap

- Many unit tests, a solid layer of component tests with React Native Testing Library, a few e2e flows with Maestro or Detox.
- Query by role and text, the way a user finds things.
- Mock the network, cover loading/empty/error states and pin every fixed bug with a test.

## Try it

The Do tab has you add Jest and React Native Testing Library to your project, write a component test, and optionally run a Maestro flow on an emulator.


Write unit and component tests with Jest and React Native Testing Library, and an e2e flow.

Testing mobile apps

What Is React Native Testing Library

Henry Moulton – React Native end-to-end testing with Maestro | App.js Conf 2023

Create a screen that renders 2,000 generated rows (title, amount, date) with a FlatList whose `renderItem` is an inline arrow that also formats the date and amount on every render.

Open the developer menu, turn on the Performance Monitor, scroll fast, and write down the lowest JS and UI frame rates you see.

Open React DevTools from the Expo CLI (press `j`), record a profile while scrolling and toggling some parent state, and note which components re-render.

Add `keyExtractor`, wrap the row in `React.memo`, and pass a stable `onOpen` callback made with `useCallback` instead of a new arrow per row.

Pre-format the amount and date once when the data is created, and add `getItemLayout` with a fixed row height.

Measure again with the same steps, ideally in a release-like run (`npx expo start --no-dev --minify`), and compare the numbers with your first ones.

Optional: replace FlatList with FlashList (`npx expo install @shopify/flash-list`) and measure a third time.

## Why it matters

Users notice slowness more on phones than anywhere else: a list that stutters while scrolling, a button that responds a beat late, an app that takes four seconds to open. Many users own older, cheaper Android devices, so an app that feels fine on a new iPhone can be painful for them. Performance work is a mid-level skill because it requires measuring first and fixing the right thing.

## Frames and threads

Smooth motion means rendering a frame about every **16.7 ms** at 60 frames per second (8.3 ms on 120 Hz screens). React Native work happens mainly on:

- the **JavaScript thread**, where your components render and your logic runs,
- the **UI (main) thread**, where native views are laid out and drawn.

If the JS thread is busy for 200 ms (a big re-render, a heavy calculation), taps and JS-driven animations freeze. If the UI thread is overloaded (huge view trees, big images), scrolling drops frames.

## Measure first

- The **Performance Monitor** in the developer menu shows JS and UI frame rates live.
- **React DevTools Profiler** (press `j` in the Expo CLI to open the debugger tools) records which components rendered and how long they took, and why.
- Test in a **release-like build**: development mode is much slower. Run `npx expo start --no-dev --minify` or use a preview build.
- Test on a **low-end Android phone** or emulator profile, not only your own device.

Write down a number before you change anything ("JS frame rate drops to 20 fps while scrolling 1,000 rows") so you can tell whether a fix helped.

## Worked example: fixing a slow list

A screen shows 2,000 transactions. Scrolling stutters and the profiler shows every row re-rendering whenever the parent's state changes.

```javascript
// Before
<FlatList
  data={transactions}
  renderItem={({ item }) => <Row item={item} onPress={() => open(item.id)} />}
/>
```

Fixes, in the order they usually matter:

1. **Stable keys:** add `keyExtractor={(t) => t.id}` so rows are not recreated.
2. **Memoized rows:** wrap the row in `React.memo` and pass stable props. Creating a new `onPress` arrow for every row each render defeats memo, so pass the id and a stable callback:

```javascript
const Row = React.memo(function Row({ item, onOpen }) {
  return (
    <Pressable onPress={() => onOpen(item.id)} style={styles.row}>
      <Text>{item.title}</Text>
      <Text>{formatMoney(item.amount)}</Text>
    </Pressable>
  );
});

const onOpen = useCallback((id) => router.push(`/tx/${id}`), []);
const renderItem = useCallback(({ item }) => <Row item={item} onOpen={onOpen} />, [onOpen]);

<FlatList
  data={transactions}
  keyExtractor={(t) => t.id}
  renderItem={renderItem}
  getItemLayout={(_, index) => ({ length: 64, offset: 64 * index, index })}
  initialNumToRender={12}
  windowSize={7}
/>
```

3. **Fixed row height:** if every row is the same height, `getItemLayout` lets the list skip measuring.
4. **Tune windowing:** `initialNumToRender` and `windowSize` control how many rows are kept rendered; smaller means less work and more blank space if users fling fast.
5. **Do less per row:** pre-format values once (when data arrives) instead of in every render, and use correctly sized thumbnails instead of full-size images.
6. **Consider FlashList** (`@shopify/flash-list`), which recycles row views and is often faster for very long lists.

Then measure again with the same steps.

## Other common wins

- **Startup:** load only what the first screen needs; defer heavy imports and work until after first render; keep the splash screen short.
- **Images:** serve thumbnails at display size; `expo-image` adds caching.
- **Animations:** run them on the UI thread (`useNativeDriver: true` with Animated, or Reanimated) so a busy JS thread does not stutter them.
- **Re-renders:** split contexts so a frequently changing value does not re-render the whole tree.
- **Remove `console.log` in hot paths:** logging is slow, especially in development.

## Common mistakes

- Optimizing without measuring, or measuring in development mode only.
- `ScrollView` with `map` for long lists.
- Inline arrow functions and objects as props to memoized rows.
- `useMemo` and `useCallback` everywhere "just in case": they have a cost too. Use them where the profiler shows a problem.

## Quick recap

- Aim for 60 fps: keep both the JS and UI threads under their frame budget.
- Measure with the Performance Monitor and React DevTools Profiler, in a release-like build, on a slow device.
- For lists: keys, memoized rows with stable props, `getItemLayout`, windowing, lighter rows, or FlashList.

## Try it

The Do tab walks you through building a deliberately slow list, profiling it and fixing it step by step.


Measure frame rates and renders, then fix a slow list with keys, memoization and windowing.

Performance

React Native Performance Optimisation (useMemo, useCallback, memo)

React Native Tutorial - 52 - FlatList

Learn the gestures first: open Settings > Accessibility > VoiceOver (iOS) or TalkBack (Android), read the tutorial, and set a shortcut (triple-click the side button on iOS, the volume-key shortcut on Android) so you can turn it off easily.

With the screen reader on, open your app and swipe through one screen from top to bottom. Write down every element that is unlabelled, read twice, out of order, or unnecessary.

Add `accessibilityLabel` and `accessibilityRole` to icon-only buttons, and `accessibilityState` to toggles and tabs.

Group cards or list rows with `accessible` and a combined label, and hide purely decorative images or icons.

Turn on the largest text size in your phone's settings and fix any text that is clipped or overlaps.

Repeat the screen-reader pass and count the swipes needed to reach the main action before and after.

Optional (Android): run Google's free Accessibility Scanner app on the screen and fix its top finding.

## Why it matters

Around one in six people worldwide live with a significant disability (WHO estimate), and many more use accessibility features temporarily or by preference: larger text, a screen reader in the car, reduced motion. Accessible apps reach more users, meet legal requirements in many countries and score better in store review. Phones have excellent built-in assistive technology; your job is to give it the information it needs.

## Screen readers on phones

- **VoiceOver** (iOS): Settings > Accessibility > VoiceOver. Swipe right/left to move between elements, double-tap to activate, three-finger swipe to scroll. Set the Accessibility Shortcut (triple-click the side button) so you can toggle it quickly.
- **TalkBack** (Android): Settings > Accessibility > TalkBack. Swipe right/left to move, double-tap to activate. Many phones offer a volume-key shortcut.

Before you turn either on for the first time, practise the gestures and learn how to turn it off again, because normal taps stop working while it is on.

The screen reader reads each element's **label**, **role** ("button", "heading") and **state** ("selected", "disabled").

## The key React Native props

```javascript
<Pressable
  onPress={toggleFavourite}
  accessibilityRole="button"
  accessibilityLabel="Favourite"
  accessibilityHint="Adds this recipe to your favourites"
  accessibilityState={{ selected: isFavourite }}
  hitSlop={10}
>
  <HeartIcon filled={isFavourite} />
</Pressable>
```

- `accessibilityLabel`: what the element is. Essential for icon-only buttons; without it the reader says "button" and nothing else.
- `accessibilityRole`: `button`, `link`, `header`, `image`, `switch`, `checkbox`, `tab` and more. Newer React Native versions also accept the web-style `role` prop.
- `accessibilityState`: `selected`, `checked`, `disabled`, `busy`, `expanded`.
- `accessibilityHint`: an optional short description of the result, when the label is not enough.
- `accessible={true}` on a container groups its children into one element, so a card is read as one item ("Pasta bake, 30 minutes, 4 stars") instead of five separate swipes.
- `importantForAccessibility="no-hide-descendants"` (Android) and `accessibilityElementsHidden` (iOS) hide purely decorative elements.

Text and native controls such as `Switch` and `TextInput` already expose sensible information; custom controls built from `Pressable` and `View` need these props.

## Beyond screen readers

- **Text size:** users can enlarge text (Dynamic Type on iOS, font size on Android). React Native `Text` scales by default; test at the largest sizes and let layouts wrap instead of clipping. Use `maxFontSizeMultiplier` sparingly where a layout truly cannot grow.
- **Colour contrast:** at least 4.5:1 for normal text (WCAG AA). Do not use colour alone to show state; add an icon or text.
- **Touch targets:** at least 44 pt (iOS) or 48 dp (Android), as in Mobile Development Basics.
- **Reduced motion:** `AccessibilityInfo.isReduceMotionEnabled()` lets you swap large animations for fades.
- **Focus and announcements:** after an important change (an error appears), move focus or call `AccessibilityInfo.announceForAccessibility("Payment failed")`.

## Worked example: auditing a recipe card

A card shows a photo, a title, a heart icon and a "4.5" rating with star icons. With VoiceOver on:

1. Swiping lands on the image ("image"), the title, the heart ("button") and each of five stars separately. That is eight swipes per card, and the heart has no name.
2. Fix: make the card `accessible` with a label "Pasta bake, rated 4.5 out of 5", give the heart its own label and `selected` state (so it stays a separate control), and hide the decorative stars.
3. Now each card is two swipes: the card (double-tap opens it) and "Favourite, button, selected".

Automated checks help too: React Native Testing Library's `getByRole` queries fail when roles or labels are missing, and Android's free **Accessibility Scanner** app flags small targets and low contrast. But only testing with a real screen reader shows whether the experience makes sense.

## Common mistakes

- Icon buttons with no label.
- Every decorative element announced separately.
- Disabling font scaling instead of fixing layouts.
- Colour as the only signal for errors or selection.
- Never trying the app with VoiceOver or TalkBack.

## Quick recap

- VoiceOver and TalkBack read label, role and state; give custom controls all three.
- Group related content with `accessible`, hide decoration, announce important changes.
- Support large text, sufficient contrast, big touch targets and reduced motion.
- Test with a real screen reader on a real phone.

## Try it

In the Do tab you will audit one screen of your app with VoiceOver or TalkBack, fix what you find and test again.


Make screens work with VoiceOver and TalkBack, large text and reduced motion.

Mobile accessibility

Chris DeMars – Incorporating screen readers into React Native development for improved accessibility

How to Navigate your iPhone or iPad with VoiceOver | Apple Support

Getting Started with TalkBack | #Android #Accessibility

Automated tests, performance profiling and screen-reader accessibility.

Quality

Set `version`, `ios.buildNumber` and `android.versionCode` in `app.json`, plus a final name, icon and splash screen.

Write a store listing draft in a text file: app name, a one-line subtitle, a short and a full description, and five keywords.

Take screenshots of your three most important screens on a phone or simulator; make sure they show the real app.

List every kind of data your app and its libraries collect (sign-in, analytics, crash reports, location) and draft your App Privacy / Data safety answers and a simple privacy policy.

Check the review basics: an in-app account deletion path if you have accounts, a demo login for reviewers, clear permission descriptions, no placeholder screens.

Optional, with an account: run `eas build --profile production`, then `eas submit`, and release to TestFlight or the Play internal testing track before any public release.

Write a rollout plan: staged or phased release, what you will watch (crash rate, reviews), and how you would roll back.

## Why it matters

An app is not shipped until people can install it from the App Store or Google Play. Store submission is part engineering, part paperwork: signing, version numbers, screenshots, privacy declarations and policy review. First-time submissions are often rejected for avoidable reasons, which can cost days. Knowing the process lets you plan a release instead of being surprised by it.

## Accounts and costs

- **Apple Developer Program:** $99 per year (individual or organization). Needed for TestFlight and the App Store. Organizations need a D-U-N-S number.
- **Google Play Console:** a one-off $25 registration fee. Google verifies your identity, and new personal accounts must run a closed test with a minimum number of testers for a minimum period before they can publish to production (the current rule has been 12 testers for 14 days; check Play Console Help for today's requirement).

Checked on 2026-10-23. Fees and rules change, so confirm on developer.apple.com and the Play Console Help Center before you pay or plan dates. Fee waivers exist for some non-profits, education and government organizations on Apple's program.

## What each store needs

| | App Store (App Store Connect) | Google Play (Play Console) |
|---|---|---|
| Build format | Signed `.ipa` | Signed Android App Bundle (`.aab`) |
| Testing track | TestFlight (internal and external testers) | Internal, closed and open testing tracks |
| Privacy | "App Privacy" details (nutrition label) and a privacy policy URL | Data safety form and a privacy policy URL |
| Listing | Name, subtitle, description, keywords, screenshots per device size, icon, age rating | Title, short and full description, screenshots, feature graphic, icon, content rating questionnaire |
| Review | Human and automated review against the App Review Guidelines | Automated and human review against Play policies |
| Technical rules | Built with a recent Xcode / SDK | Target a recent Android API level |

Both stores require a way to **delete an account** from inside the app if the app lets users create one, and a demo account for reviewers if features are behind a login.

## Versions and signing

Every upload needs a higher build number than the last:

```json
{
  "expo": {
    "version": "1.2.0",
    "ios": { "buildNumber": "14" },
    "android": { "versionCode": 14 }
  }
}
```

`version` is what users see; `buildNumber` / `versionCode` must increase on every upload. With EAS you can set `"autoIncrement": true` in the production profile of `eas.json` and let the build service manage it.

Signing proves the build came from you. EAS can create and store the iOS certificates and provisioning profiles and the Android upload keystore for you. **Back up the Android keystore credentials** (`eas credentials`): Google Play App Signing protects the final app signing key, but losing the upload key still means a support process to reset it.

## Worked example: from build to review with EAS

```bash
eas build --platform all --profile production      # store-ready .ipa and .aab
eas submit --platform ios                           # uploads to App Store Connect
eas submit --platform android                       # uploads to Play Console
```

Then:

1. **Test first.** On iOS the build appears in TestFlight; add yourself and a few testers. On Android, release to the internal testing track and install from the Play Store link.
2. **Fill in the listing:** description, screenshots (real app screens, no misleading images), support URL, privacy policy.
3. **Declare data use honestly:** analytics, crash reporting and sign-in all collect data. The App Privacy and Data safety answers must match what your app and its SDKs actually do.
4. **Give reviewers what they need:** a demo account, notes explaining any non-obvious features, and contact details.
5. **Submit for review.** Choose manual or automatic release after approval, and consider a **staged rollout** (Play) or **phased release** (App Store) so a problem only reaches a small share of users first.

## Common rejection reasons

- Crashes or broken features during review (test the exact build you submit).
- Missing or vague permission usage descriptions.
- Login required with no demo account provided.
- Privacy declarations that do not match the app's behaviour or its SDKs.
- Placeholder content, "beta" labels or links to unfinished features.
- Payments for digital goods outside the store's in-app purchase system where the rules require it (the rules differ by region and change; read the current guidelines).

## Quick recap

- Accounts: Apple $99/yr, Google $25 one-off (checked on 2026-10-23); confirm on the official sites.
- Increase the build number every upload; let EAS manage signing and back up credentials.
- Test through TestFlight and Play testing tracks, fill in privacy declarations honestly, give reviewers a demo account.
- Roll out in stages so problems reach few users.

## Try it

The Do tab is a release checklist you can work through for your own app, with or without paid accounts.


Prepare signing, versions, listings and privacy declarations, and get through store review.

App store submission

How to Publish Your App to the App Store (Step by Step, 2026)

How to Publish Your App to the Play Store (Step by Step, 2026)

Create a free Sentry account (or a free Firebase project for Crashlytics) and a React Native project to get a DSN.

Run `npx expo install @sentry/react-native`, add its config plugin to `app.json`, and call `Sentry.init` with your DSN and `sendDefaultPii: false`.

Add a hidden test button that throws an error, build a development or preview build (Sentry's native crash handling is not available inside Expo Go), trigger the error, and find it in the dashboard.

Check what the report contains (device, OS, release, breadcrumbs) and confirm it holds no personal data.

Optional: run `npx expo install expo-updates` and `eas update:configure`, install a preview build on your phone, change some text, and run `eas update --channel preview --message "Text fix"`. Restart the app twice to see the update.

Write down which changes you could ship by OTA and which would need a new store build.

Clean up: remove the test button, and delete any Sentry or Firebase project you will not keep using.

## Why it matters

Once real people use your app, two questions matter every day: "Is it crashing for anyone?" and "How fast can we ship a fix?" Crash reporting answers the first. A repeatable build pipeline and over-the-air (OTA) updates answer the second. Together they turn releases from stressful events into routine work.

## Build profiles

With EAS, `eas.json` defines build profiles, usually three:

```json
{
  "build": {
    "development": { "developmentClient": true, "distribution": "internal" },
    "preview": { "distribution": "internal", "channel": "preview" },
    "production": { "autoIncrement": true, "channel": "production" }
  }
}
```

- **development:** your own dev client for daily work.
- **preview:** an internal build that testers install, pointed at a staging API.
- **production:** the store build.

Use environment variables (EAS environment variables or `app.config.js`) for per-profile settings such as the API URL. Never put secrets in them if they end up in the JavaScript bundle; anything the app ships is readable.

You can trigger builds from CI (GitHub Actions or EAS Workflows) on every merge to the main branch, so every build is reproducible and nobody ships from a laptop with uncommitted changes. The free EAS plan has a limited number of builds per month; check expo.dev/pricing (checked on 2026-10-23).

## Over-the-air updates

A React Native app has two parts: **native code** (compiled into the binary) and the **JavaScript bundle plus assets**. EAS Update lets you publish a new JavaScript bundle that installed apps download on their next launch, without a store review:

```bash
npx expo install expo-updates
eas update:configure
eas update --channel production --message "Fix crash on empty cart"
```

Rules that keep OTA safe:

- **JavaScript and assets only.** Changing native code (adding a native library, changing permissions or the SDK version) needs a new store build.
- **Runtime version.** Each build has a `runtimeVersion`; an update is only delivered to builds with a matching one, so a JavaScript bundle never lands on a binary that lacks the native code it needs. The `"policy": "fingerprint"` setting derives it from your native code automatically.
- **Store policies.** Both stores allow interpreted code updates for bug fixes and small improvements, but not changes to the app's core purpose that bypass review. Use OTA for fixes, not to ship a different app.
- **Roll out gradually** (EAS Update supports percentage rollouts) and keep the ability to roll back to the previous update.

## Crash reporting

Users rarely report crashes; they just leave. A crash reporter catches errors on the device and sends them to a dashboard with the stack trace, device model, OS version, app version and the steps (breadcrumbs) leading up to the crash. Popular choices are **Sentry** (`@sentry/react-native`, with an Expo config plugin) and **Firebase Crashlytics**. Both have free tiers suitable for learning (checked on 2026-10-23).

```javascript
import * as Sentry from "@sentry/react-native";

Sentry.init({
  dsn: process.env.EXPO_PUBLIC_SENTRY_DSN,   // a DSN is not a secret, but keep it configurable
  environment: __DEV__ ? "development" : "production",
  sendDefaultPii: false,                      // do not send personal data by default
});

export default Sentry.wrap(App);
```

Two production details matter:

- **Source maps.** Production JavaScript is minified, so stack traces look like `a.b is not a function at 1:20934`. Uploading source maps for each build and update turns them back into your file names and line numbers. The Sentry Expo integration can do this during EAS builds and updates.
- **Privacy.** Do not attach tokens, emails or form contents to error reports. Declare crash data in the store privacy forms.

## Worked example: a fix in under an hour

1. 10:02: crash alerts show `TypeError: Cannot read properties of undefined (reading 'total')` in `CartSummary`, 3% of sessions, version 1.4.0, only for users with empty carts.
2. 10:10: the source-mapped stack trace points to `cart.items[0].total`. You add a guard and a unit test for the empty cart.
3. 10:25: CI passes. You publish `eas update --channel production` to 10% of users.
4. 10:45: the crash rate for the new update is zero; you roll out to 100%.
5. Later: the native build is unchanged, so no store review was needed.

## Common mistakes

- OTA updates that require native code the installed build does not have (use runtime versions).
- No source maps, so crash reports are unreadable.
- Sending personal data in crash reports or logs.
- Builds made by hand on one laptop, so nobody can reproduce them.
- No staged rollout, so a bad update reaches everyone.

## Quick recap

- Define development, preview and production build profiles; build from CI.
- EAS Update ships JavaScript and asset fixes over the air, matched by runtime version, rolled out gradually.
- Crash reporting with uploaded source maps tells you what broke, where and for whom, without collecting personal data.

## Try it

The Do tab has you add crash reporting to your app on a free tier, trigger a test error and, if you want, publish an OTA update.


Set up build profiles, crash reporting with source maps and safe over-the-air updates.

Builds, updates, and crash reporting

When to use over the air updates | Three important OTA use cases

Monitoring Critical User Experiences In React Native Mobile Apps

## Why it matters

React Native and Expo cover most of what apps need, but sooner or later a project hits something they do not: a vendor's payment terminal SDK that only ships for Swift and Kotlin, a brand-new OS feature, a performance-critical image filter. Mid-level mobile developers are expected to recognise when that point arrives and to know how JavaScript and native code meet, even if a native specialist writes the Swift or Kotlin.

## How JavaScript talks to native code

In React Native's **New Architecture** (the default since React Native 0.76):

- **JSI** (JavaScript Interface) lets JavaScript call C++ objects directly and synchronously, instead of sending serialized messages over the old asynchronous bridge.
- **Turbo Modules** are native modules (functions) exposed through JSI and loaded lazily, when first used.
- **Fabric** is the renderer that turns React's component tree into native views; custom native **components** (views) plug into it.
- **Codegen** reads a typed JavaScript/TypeScript spec of your module and generates the native glue code, so both sides agree on the types.

In Expo projects the usual tool is the **Expo Modules API**, which lets you write a module in Swift and Kotlin with a small, declarative syntax:

```swift
// ios/BatteryModule.swift
import ExpoModulesCore

public class BatteryModule: Module {
  public func definition() -> ModuleDefinition {
    Name("Battery")
    Function("level") { () -> Float in
      UIDevice.current.isBatteryMonitoringEnabled = true
      return UIDevice.current.batteryLevel
    }
  }
}
```

```kotlin
// android/.../BatteryModule.kt
class BatteryModule : Module() {
  override fun definition() = ModuleDefinition {
    Name("Battery")
    Function("level") {
      val bm = appContext.reactContext?.getSystemService(Context.BATTERY_SERVICE) as BatteryManager
      bm.getIntProperty(BatteryManager.BATTERY_PROPERTY_CAPACITY) / 100f
    }
  }
}
```

```javascript
// JavaScript
import { requireNativeModule } from "expo-modules-core";
const Battery = requireNativeModule("Battery");
console.log(Battery.level());   // 0.82
```

The same name and function exist on both platforms, and JavaScript calls one API. (Expo already ships `expo-battery`; this is only to show the shape.) Because the module contains native code, it needs a **development build**; it cannot run in Expo Go. **Config plugins** let a module change native project settings (Info.plist entries, Android manifest permissions) automatically during the build.

## When to go native

Reach for native code when:

- **A required SDK is native-only** and no maintained React Native wrapper exists.
- **You need a new platform feature** (widgets, Live Activities, App Clips, watch apps, CarPlay) that has no library yet. Many of these are separate native targets anyway.
- **Measured performance** is not good enough after JavaScript-side fixes: heavy image or audio processing, real-time graphics, large on-device computation.
- **Deep OS integration**: background services, Bluetooth peripherals with strict timing, custom keyboards.

Stay in JavaScript when a well-maintained library already does it (check its downloads, recent releases and New Architecture support), or when the "slowness" has not been measured. Every native module adds two languages to maintain, two sets of platform tests and upgrade work with each React Native release.

At the far end, some teams write whole screens or the whole app natively (Swift with SwiftUI, Kotlin with Jetpack Compose). That is a product decision about team skills and long-term cost, not just a technical one. **Brownfield** apps go the other way: an existing native app adds React Native for some screens.

## Worked example: a decision

A delivery app must print receipts on a Bluetooth printer whose vendor ships only an iOS framework and an Android AAR.

1. Search for an existing React Native wrapper: one exists but has had no release in three years and does not support the New Architecture. Not a safe dependency.
2. Decide: write a small Expo module with two functions, `connect(address)` and `printReceipt(lines)`, wrapping the vendor SDKs, with a config plugin that adds the Bluetooth permission strings.
3. Keep the module thin: formatting the receipt stays in JavaScript (tested with Jest); native code only talks to the printer.
4. Plan for maintenance: a native engineer reviews the Swift and Kotlin, and the module gets its own tests on each platform.

## Common mistakes

- Going native for performance before profiling.
- Large native modules full of business logic that is hard to share and test; keep logic in JavaScript and native code thin.
- Abandoned community libraries without New Architecture support.
- Forgetting that native changes need a new store build and a new runtime version for OTA updates.
- Implementing a feature on one platform only and leaving the other to crash.

## Quick recap

- The New Architecture connects JavaScript and native code through JSI, Turbo Modules, Fabric and Codegen.
- In Expo, the Expo Modules API and config plugins are the standard way to add native code; it requires a development build.
- Go native for native-only SDKs, new platform features, measured performance needs and deep OS integration; otherwise prefer maintained libraries.

## Try it

Take the quiz in the Do tab. If you have time, list the native features your dream app would need and check whether a maintained library covers each one.


Explain how JavaScript and native code connect and decide when a native module is worth it.

When to go native

How to create a native module with the Expo modules API

The New React Native Architecture

Store submission, builds, over-the-air updates, crash reporting and when to go native.

Mobile App Production

About this course

Course content

App Architecture

Quality

Release

Where this course leads

Careers that use it