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

Mobile App Production

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.