13 Prompts That Turn an LLM Into a React Native Teammate: From Navigation and FlatList to the App Store Build

Shipping a React Native app is 20% feature work and 80% fighting the same five problems: a stack that refuses to reset, a FlatList that drops frames, an Expo config that builds locally but fails in EAS, a release that gets rejected for a missing privacy manifest, and a crash you can only reproduce on one Android device. None of these are intellectually hard. They are just repetitive — and that is exactly the kind of work an LLM does well, if you feed it the right prompt.

Below are 13 prompts I keep in a project-level prompts/ folder next to app.json. Each is a complete scenario: what problem it solves, the prompt itself, and a real example of the output. They assume React Native with Expo (SDK 51+ conventions, but the logic holds for bare workflows too). Copy them, adjust the placeholders, and stop re-explaining your stack to the model every morning.

The one rule that makes all 13 work A prompt without context produces generic boilerplate. Every recipe below starts by pinning versions, the router, and the platform target — because "use React Navigation" means three different APIs depending on whether you are on v6 or v7.

Navigation: stop guessing which API you are on

1. The stack-reset debugger

Task: your login flow leaves the previous screen in the back stack, so pressing "back" on the home screen returns to the login form.

Prompt:

You are a React Native engineer. Stack: Expo SDK 51, React Navigation v6,
@react-navigation/native-stack. Problem: after successful login the user can
swipe back into the auth stack. Here is my navigator tree: <paste>. Explain why
resetting with navigation.navigate() fails here, and give me the exact code
using CommonActions.reset to replace the whole stack. Show the before/after
state of the navigation state object.

Example result: the model explains that navigate('Home') pushes onto the existing stack rather than replacing it, then returns:

navigation.dispatch(
  CommonActions.reset({ index: 0, routes: [{ name: 'Home' }] })
);

and a diff of the state object showing routes going from [Login, Home] to [Home]. The insight you would not get in five minutes: the bug is not in the login screen, it is in the navigator's initial route config.

2. Deep link → screen mapping

Task: you have universal links like myapp://order/42 and need them mapped to nested navigators.

Prompt:

Generate a React Navigation linking config for these URL patterns:
myapp://order/:id -> OrderDetails inside HomeTabs > OrdersStack
myapp://promo/:code -> Promo inside HomeTabs
Ask me about edge cases before writing code (missing params, expired promo).

Example result: a linking object with config.screens nested exactly as specified, plus a list of three edge cases the model flagged — including that a missing :id silently renders undefined, so the screen needs a guard.

Where people go wrong They paste a prompt without the navigator tree. The model then invents a plausible tree and the fix compiles but does not match your app. Paste the tree — it is 10 lines.

Lists that do not stutter

3. FlatList performance audit

Task: a feed of 500 items scrolls at what feels like 30 fps on mid-range Android.

Prompt:

Review this FlatList for performance. React Native 0.74, Hermes on.
<paste component>. Identify: missing keyExtractor, unstable renderItem,
inline styles in renderItem, missing getItemLayout, and any prop that forces
re-render of every row. For each, state the cost and the fix. Then rewrite it.

Example result: the model catches that renderItem is defined inline (new function identity every render, defeating memoization), that ItemSeparatorComponent is an anonymous arrow, and that getItemLayout is impossible here because rows have variable height — so it suggests estimatedItemSize via FlashList instead. That last point is the trade-off most tutorials skip.

Symptom Likely cause Fix
Every row re-renders on scroll inline renderItem useCallback + React.memo row
Blank flashes while scrolling no windowing config tune windowSize, maxToRenderPerBatch
Janky on Android only heavy shadows / images expo-image, removeClippedSubviews

4. The pagination contract

Task: infinite scroll that double-fires requests on fast scroll.

Prompt:

Write a useInfiniteFeed hook for React Native. Requirements: cursor-based
pagination, no duplicate in-flight requests, dedupe by id, refetch on pull-to-
refresh, expose { data, loading, error, loadMore, refresh }. Explain how you
prevent the double-fire race.

Example result: a hook with a useRef in-flight guard and an AbortController per request, plus a one-paragraph explanation of why loading state alone is not enough (state updates are async; the guard must be a ref).

Expo config and builds

5. app.json vs app.config.ts

Task: you need per-environment config (dev/staging/prod) with different bundle IDs.

Prompt:

Convert my static app.json to a dynamic app.config.ts that reads APP_VARIANT
from process.env. Show how eas.json profiles map to it, and how to keep the
bundle identifier unique per variant so they install side by side.

Example result: a config exporting a function, with ios.bundleIdentifier and android.package suffixed by the variant, and three eas.json profiles wired to APP_VARIANT. The non-obvious bit: two apps with the same package name overwrite each other on the device, which is why the suffix matters.

6. Native module that only fails in EAS

Task: a build works locally with expo run:android but fails in the cloud.

Prompt:

Local build passes, EAS build fails with this error: <paste log tail>.
My package.json: <paste>. Walk me through the five most common causes of
local-vs-EAS divergence (native dirs, prebuild, node version, secrets,
architecture), and tell me which one this log points to.

Example result: the model spots a stale android/ folder committed to git, explains that EAS runs prebuild clean while local runs against the committed folder, and gives the fix: add android/ and ios/ to .gitignore if you rely on CNG (continuous native generation).

Key distinction A "it works on my machine" bug in Expo is almost always a state difference, not a code difference. Ask the model to diff the *environment*, not the source.

Debugging crashes and device-only bugs

7. Crash log interpreter

Task: a red screen or a native crash you cannot read.

Prompt:

Here is a React Native crash log from Android: <paste>. App uses Expo SDK 51,
Hermes, react-native-reanimated 3.x. Translate this stack into plain English,
name the module responsible, and give me the smallest reproduction and the fix.

Example result: the model identifies a NullPointerException inside Reanimated's worklet as a value captured from a mutable ref, explains that worklets run on a separate thread and cannot read JS refs, and suggests passing the value as an argument.

8. The device-only repro checklist

Task: a bug appears only on iOS 17 or a specific Android OEM.

Prompt:

Give me a minimal repro checklist for a bug that appears only on <device/OS>.
Include: how to check if it is a Hermes/JSC difference, how to enable the
Flipper/React DevTools, how to capture a native stack with adb logcat, and
what to log to prove the hypothesis. Format as numbered steps.

Example result: an ordered checklist ending with the adb logcat filter command, plus a note that Hermes and JSC differ in how they stringify certain objects — a real source of "works on iOS, breaks on Android" bugs.

Release to the stores

9. App Store rejection pre-mortem

Task: you are about to submit and want to catch the common rejection reasons first.

Prompt:

My app: <one-line description>. It uses <permissions: camera, location,
notifications>. Before I submit to the App Store, list the rejection reasons
most likely to hit me, and for each give the exact Info.plist key or App Store
Connect field I must fill. Be specific, cite the guideline number.

Example result: a table of likely rejections — missing purpose strings for camera/location, missing account deletion, a privacy manifest for required-reason APIs — each mapped to the concrete key or field. The model correctly points to guideline 5.1.1 for data collection and purpose strings.

10. Versioning and build numbers

Task: you keep bumping version by hand and forgetting buildNumber.

Prompt:

Write a script for an Expo app that bumps the semver patch on every EAS
production build and auto-increments ios.buildNumber and android.versionCode.
Show how to run it as an EAS build lifecycle hook (eas-build-pre-install or a
custom script), and warn me about what can go wrong if two builds run in parallel.

Example result: a Node script plus the eas.json hook, and a warning that parallel builds can collide on the same build number — so the increment must happen server-side or be unique per build.

What to check first Before any release prompt, force the model to name the store guideline or config key. If it cannot, it is guessing, and a guessed rejection reason wastes a review cycle (often days).

The daily-driver prompts

11. TypeScript migration of one screen

Task: a legacy JSX screen you want typed without rewriting it.

Prompt:

Convert this screen to TypeScript, inferring prop types from usage.
<paste>. Do not change runtime behavior. List every place where you had to
choose between `any` and a real type, and why.

Example result: typed props plus an explicit list of the three any escape hatches and the reason for each — so you can review the risky ones instead of trusting the diff.

12. Test the reducer, not the UI

Task: you want confidence without brittle snapshot tests.

Prompt:

Given this reducer <paste>, write Jest tests covering: happy path, an unknown
action, and an action with a missing payload field. Use table-driven tests.
Point out any state transition that my reducer allows but probably should not.

Example result: a test.each table plus a flagged transition — an action that can move state to loading: true without ever clearing it, a real bug the tests exposed.

13. The onboarding-to-release checklist

Task: the meta-prompt that ties it together before a launch.

Prompt:

Act as a release manager for a React Native/Expo app. Produce a pre-release
checklist grouped by: config (app.json, eas.json), assets (icon, splash,
adaptive icon), permissions and privacy, testing on both platforms, and store
submission. For each item, give the exact file or command to verify it.

Example result: a grouped checklist where every line names a file or command — eas.json profiles, npx expo-doctor, adaptive icon in app.json, and the store submission step. It is the prompt I run the day before every release.

What this collection actually buys you

The value is not the 13 answers — it is the habit of framing each daily chore as a scenario with pinned context: versions, the failing log, the navigator tree. A model given that context behaves like a teammate who read your repo; given a vague one-liner, it writes tutorial code for an app that is not yours.

Start with the three you hit most often — navigation resets, FlatList jank, and the EAS-vs-local build — and keep them in prompts/ alongside your config. If you are also tightening the rest of your engineering loop, the Git & GitHub course covers the commit hygiene that makes these prompts easier to feed, and the Data Science Prompts That Actually Work shows the same scenario-first pattern applied to a different domain.

← All posts

Ask AI about this article

Ask a question about this article — ASI Biont will answer based on its text.