React Native Roadmap

Mirror of GUIDES/ReactNative/00-roadmap.md, the canonical copy — edit there first, then re-sync this file.

The ordered build plan for a React Native app: nine phases from a blank idea to a monitored store release. One phase at a time — no phase starts before the previous deliverable exists. Estimates assume one experienced developer; solo, double them.

The chapters are reference. This file is what actually moves the project forward.

Phase 0 — Idea → spec (½–2 days)

Goal: a written definition of the app before any tooling.

One-paragraph product statement ("For [user], this app does [job], unlike [alt]")
Up to 10 user stories for release 1 — resist more
Screen inventory: name + one line per screen (this becomes your route table)
Data model draft: entities, IDs, relationships
Non-functional requirements: auth? offline? realtime? payments? media? i18n?
Map the nouns to feature folders (01. App architecture → "From idea to modules")

Deliverable: one page a stranger could build from.

Read: 01.

Phase 1 — Foundation (1–2 days)

Goal: an empty but correct project: runs on a device, type-checks, lints, CI green.

Toolchain installed and versions pinned: Node 22.13+, pnpm, JDK, Android Studio; Xcode on macOS (02)
pnpm create expo-app (Expo Router template), git initialised, .nvmrc + engines set
Folder skeleton created from templates/folder-structure.txt
TypeScript strict + path aliases (templates/tsconfig.paths.json)
ESLint 9 flat config with boundary rules + Prettier + husky + lint-staged (templates/eslint.config.js)
CI job on every PR: lint → typecheck → unit tests → build (13)

Deliverable: main with a green pipeline; the app launches and shows one screen on both platforms.

Read: 02, 03.

Phase 2 — Walking skeleton (3–5 days)

Goal: one thin slice of real value, end to end: screen → state → API → data → back.

Root layout: providers (query client, theme, safe area) and the top-level routes (07)
API client with typed endpoints, interceptors, normalized errors (templates/api-client.ts, 05)
One feature delivered completely inside its folder (templates/feature-module/, 03)
Loading, empty, error and offline states handled — not skipped
Sentry wired, even if only logging to console for now (14)

Deliverable: a demoable app with one genuinely useful feature.

Read: 04, 05, 07.

Phase 3 — Core capabilities (1–2 weeks)

Goal: the machinery every later feature needs exists once, correctly.

Design tokens + light/dark theming + typography scale (06)
UI primitives: Button, Input, Card, List skeleton, Screen, Text variants
Form pattern: react-hook-form + zod + server-error mapping (08)
Auth flow: sign in/up, token storage, refresh, logout cleanup (09)
Storage layer: secure store for tokens, MMKV for prefs (05)
Navigation guards: bootstrapping → signedOut → signedIn (07)

Deliverable: new features become mostly composition.

Read: 06, 08, 09.

Phase 4 — Feature build-out (weeks, variable)

Goal: the remaining product features, each as a vertical slice.

Feature per slice, same internal layout, public API via index.ts
Realtime where needed (websocket/SSE with reconnection) (05)
Offline/caching strategy applied where the product needs it (05)
Pull-to-refresh, pagination, and empty states on every list
Accessibility labels added as the UI is written, not retrofitted (06)

Deliverable: feature-complete against the Phase 0 spec.

Phase 5 — Quality (3–5 days + ongoing)

Goal: confidence that change does not break things.

Unit tests on domain logic, hooks and reducers (10)
Component tests on the critical screens with RNTL (remember: await render(...))
Maestro E2E smoke flows: onboarding, auth, the money path (10)
Performance budget set and met: cold start, TTI, 60 fps scroll (11)
FlashList everywhere lists matter; re-render audit on hot screens (11)
Accessibility pass: screen reader walkthrough, dynamic type, touch targets (06)

Deliverable: green suite in CI + recorded performance numbers.

Phase 6 — Hardening (2–4 days)

Goal: safe to hand to strangers.

Security pass against 12. Security and the 81-checklist
No secrets in the bundle; PII scrubbed from logs and breadcrumbs (12)
Structured logging + analytics event taxonomy shipped (14)
Crash-free rate, app-start p95 and slow frames on a dashboard (14)
Deep links validated; WebView allowlisted if used (12)

Deliverable: a live health dashboard and a passed checklist.

Phase 7 — Release (3–7 days, dominated by store review)

Goal: published on both stores.

Apple Developer + Google Play accounts, team roles, signing via EAS (13)
eas.json profiles: development, preview, production (13)
Distinct dev/staging/prod identifiers and API base URLs (13)
Store listings, screenshots, privacy labels, permission rationales (13)
Review account/credentials and an IAP decision made before submission (13)
OTA update proven with a harmless change; rollback rehearsed (13)

Deliverable: 1.0 in users' hands; staged rollout enabled.

Phase 8 — Operate & iterate (forever, ~1 h/week)

Goal: the app gets better instead of older.

Weekly triage: crashes, top funnels, ANR, store reviews (14)
Feature flags for the next train; flags expired on a schedule (14)
Dependency upgrades on a cadence (Renovate weekly) (15)
Quarterly: re-run the 81-checklist, revisit ADRs (15)

Rules that keep this roadmap honest

Walking skeleton before features. One thin end-to-end slice beats five half-built screens.
No phase skips. Tests after Phase 5 are cheap; tests retrofitted in Phase 7 are not.
Deliverables are binary. Each phase ends with something that exists or does not.
Cut scope, not structure. A smaller feature set in a sound codebase ships; the reverse rarely does.
Re-estimate at each phase boundary. The roadmap is a living document — update it as reality diverges.

← README · Guide home · 01. App architecture →