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.