What this prompt does
This prompt asks the AI to act as a senior mobile engineer and specify a production React Native architecture tightly enough to build from, with a real directory tree and concrete library choices. You provide the [app_type], your [state_pref], the [api_style], and the [distribution] channel, and it returns the directory tree, a decisions table, and key wiring snippets in fenced blocks.
The five deliverables cover the load-bearing decisions: a folder structure for features, navigation, services, hooks, and components with a one-line purpose per directory; typed navigation via React Navigation; state using your [state_pref] plus server-state via TanStack Query and a typed API client for your [api_style]; an offline sync strategy that caches, queues mutations, and reconciles on reconnect; and push, crash reporting, and OTA updates wired to your [distribution], each with a decisions table entry (choice, why, tradeoff). The structure forces the model to lock navigation typing and offline behaviour up front, which is brutal to retrofit later.
When to use it
- You are starting a new React Native app and want the architecture decided before the first screen.
- You need typed navigation routes and params rather than stringly-typed navigation.
- Your app must work offline and reconcile mutations when the network returns.
- You want push notifications, crash reporting, and OTA updates wired to a specific distribution channel.
- You are bringing React habits to mobile and want patterns that respect a phone is not a browser.
Example output
You get a directory tree showing features, navigation, services, hooks, and components with a one-line purpose each; a decisions table listing every infrastructure choice with its rationale and tradeoff; and wiring snippets for typed navigation, the TanStack Query setup, the API client for your [api_style], and the offline sync queue.
Pro tips
- Set
[state_pref]to what your team already knows; the prompt honours your choice and pairs it with TanStack Query for server state, so do not duplicate server data in your client store. - Match
[api_style]precisely (REST, GraphQL, JWT vs session) so the generated typed API client fits your backend. - Decide what happens to in-flight mutations when the network drops before writing the first screen - that single choice shapes the whole offline layer.
- Tie
[distribution]to your real channel so the OTA, push, and crash-reporting wiring matches your build pipeline. - Treat the decisions table as a living doc; the tradeoff column is where you catch choices you will regret.
- If navigation params come back untyped, push back - typed routes are the cheapest bug prevention you get on mobile.
- Keep each top-level directory's one-line purpose in the tree; it is the cheapest onboarding doc you will ever write for a new contributor.
- Pin concrete library versions in the decisions table, since a phone build is far more sensitive to native dependency drift than a browser app.
