React Native apps drift in specific ways: a screen that re-renders on every keystroke, a navigation stack that keeps 30 screens mounted, a third-party native module that worked on the old bridge but silently misbehaves now that 0.82 forced everyone onto the New Architecture. Profiling finds these, but only if you know where to point the profiler. An AI audit gives you the “where to look first” list so the next hour in React Native DevTools actually pays off.
TL;DR
Feed an LLM your project tree, package.json, and your 3 highest-traffic screens, then run four targeted audit prompts (render, navigation, list, native modules). You get a ranked hotspot list with file paths. Then you verify every claim in a profiler before you fix anything. As of June 2026 the relevant baseline is React Native 0.82 (New Architecture is mandatory; the old bridge is gone), React Native DevTools as the debugger (Flipper is removed), and FlashList v2 or LegendList for large lists.
What this covers
A focused workflow that prioritizes what RN apps actually break on: render performance, navigation memory, native-module compatibility on the New Architecture, list virtualization, image handling, and iOS-vs-Android divergence. The output is a ranked hotspot list with file paths, not a generic “make it faster” lecture.
Key tools and concepts:
- React Native New Architecture: Fabric (the C++ renderer) plus TurboModules (JSI-based native modules, loaded lazily). Default since 0.76, and the only option from 0.82 onward (the legacy bridge was removed). This is the single biggest variable in any 2026 audit.
- Hermes: RN’s default JS engine. React Native DevTools and the Performance Panel are built around Hermes, so most profiling assumes you are on it rather than JSC.
- Re-render: A component re-evaluating without producing a different output. In practice this is still the #1 RN performance complaint, usually traced to inline functions, unstable object props, or over-broad Context.
Who this is for
RN developers shipping production apps (solo, agency, or in-house), especially when you can’t reproduce a “slow on user devices” complaint locally and need a structured way to narrow the search. It is also useful right after a version bump, where most regressions hide.
When to reach for it
- Quarterly maintenance.
- Before an App Store / Play Store submission, especially the first release after a major refactor.
- After an RN upgrade. Crossing the New Architecture boundary (anything below 0.76 → 0.82) is the highest-risk jump, because native modules that relied on the old bridge can break.
- When a complaint mentions “slow,” “jank,” or “crashes on Android only.”
Before you start
- Run
tree -L 3 -I node_modules srcand paste the output as orientation for the AI. - State your exact RN version, your Expo SDK if you use Expo (SDK 54 was the last to allow legacy arch; SDK 55 ships RN 0.83), and whether you are bare or managed. The audit prompts shift based on these.
- Identify the 2-3 screens users hit most. Audit those first, not rarely-used flows.
Step by step
- Give the AI the project tree,
package.json, and your top-3 high-traffic screen file paths. State your RN version and confirm you are on the New Architecture (you almost certainly are on 0.82+). - Run the render-performance audit:
Inspect [list of high-traffic screen files]. List the top 5
likely re-render hotspots. For each: which component, what
triggers extra renders (inline functions, unstable object
props, broad Context consumers), and the minimal fix
(useCallback, useMemo, React.memo, or splitting Context).- Run the navigation audit:
Inspect navigation setup (React Navigation v7 or Expo Router).
Flag: deeply nested stacks that keep too many screens mounted,
missing screen options that disable expensive features
(headerLargeTitle, gesture handlers), and any screen that
mounts on launch but should be lazy.- Run the list / data audit:
For each FlatList / SectionList / VirtualizedList in the
codebase, check: stable keyExtractor, getItemLayout for
fixed-height rows, and whether the list should migrate to
FlashList v2 or LegendList given its item count. Flag image
components inside cells still using RN <Image> instead of
expo-image.- Run the native-module audit:
List third-party native modules in package.json. For each,
note: New Architecture (TurboModule/Fabric) compatibility,
iOS vs Android behavior differences, and known issues on my
RN version. Flag any module whose last release is > 12 months
old or that has an open New Architecture compatibility issue.- Profile what the AI flagged. Don’t trust hypotheses. Verify with React Native DevTools (the React profiler and, on 0.83+, the Performance Panel), Xcode Instruments for the iOS native thread, and Android Studio Profiler for the Android native thread.
- Fix with tests, then re-run the audit on the changed code. Regressions hide inside fixes.
List library decision (June 2026)
The list audit usually ends with “should this be FlashList or LegendList?” Here is the honest rule of thumb:
| Library | Best for | Why |
|---|---|---|
FlatList (built-in) | Lists under ~500 items | Fine, no extra dependency; degrades past a few hundred rows because it destroys and recreates cells |
FlashList v2 (Shopify) | Most production lists, 500+ items | Cell recycling instead of pure virtualization; v2 is a New-Architecture rewrite that drops estimatedItemSize and sizes items automatically |
LegendList | Feeds/chat/media where scroll is a core feature | Built specifically for the New Architecture; holds 60fps on mid-range Android with large, complex rows where FlashList occasionally drops frames |
Note the v2 migration detail: if you upgrade FlashList, remove estimatedItemSize, estimatedListSize, and estimatedFirstItemOffset — v2 ignores them. See the FlashList docs.
First-run exercise
- Pick your single most-used screen and run only the render-performance audit on it.
- For each of the 5 hotspots, open the React profiler in React Native DevTools and verify. Expect roughly 3-4 to hold up and 1-2 to be wrong. That is normal for hypotheses generated from code patterns.
- Fix one verified hotspot, re-profile, and record the actual frame-time change (or lack of one).
- You now have ground truth for this app: which audit predictions are reliable. Use that calibration on the rest of the codebase.
Quality check
- Did the AI cite specific files and components? “Performance could be better” is not actionable.
- Are claimed hotspots reproducible in a profiler? If you can’t trigger the slowness it describes, downgrade that finding to “investigate later.”
- Did it separate iOS from Android impact? Many RN issues are platform-specific; conflating them wastes profiling time.
- For native-module flags, did you check the module’s actual repo (last release date, open New Architecture issue)? AI confidently hallucinates compatibility claims, so this step is non-negotiable.
Common mistakes
- Trusting AI hotspot claims without profiling. The AI is hypothesizing from code patterns; the profiler is ground truth.
- Auditing the whole codebase at once. You get 50 findings and fix none. Top-3 screens first.
- Skipping the navigation audit. Apps with 30+ screens often retain memory in ways a render profiler won’t surface; you have to go look at the stack.
- Skipping the native-module compatibility check on upgrades. The 0.76 → 0.82 jump that removes the old bridge is exactly where modules break.
- Asking about “Flipper.” It was deprecated in 0.73-0.74 and is no longer in the templates. Tell the AI you use React Native DevTools so its advice matches reality.
- Treating React render count as the only signal. Also look at JS-thread time in DevTools and native-thread time in Xcode Instruments / Android Studio Profiler.
FAQ
- Does this work for Expo apps?: Yes. Point the AI at
app.config.js/app.jsonin addition topackage.json, since Expo abstracts native config. If you are still on Expo SDK 54 with legacy arch, say so; SDK 55 (RN 0.83) requires the New Architecture. - What changed with the New Architecture being mandatory?: From RN 0.82 there is no opt-out, so every native module must be a TurboModule/Fabric-compatible build. The native-module audit is the part of this workflow that matters most after an upgrade.
- Can the AI fix the issues it finds?: Yes for code-level fixes (memoization, prop stabilization, list migration). Native-module problems usually need a human plus the module maintainer.
- How does this compare to a paid RN consultancy audit?: A consultancy goes deeper and adds architectural judgment. An AI audit covers a large share of routine findings (re-renders, list misuse, dead modules) at a tiny fraction of the cost, and it is fast enough to run every quarter.
- Which model?: Use a coding model with repo-wide file access. Claude Opus 4.7 or Sonnet 4.6 in Claude Code, or GPT-5.5 in Codex, both handle cross-file RN reads well. Cursor’s agent mode works for the same reason.
Related
- App audit prompt workflow
- AI agent code review workflow
- AI architecture review workflow
- AI debug workflow
Tags: #AI coding #Tutorial