Memory Leak Debugging in React Native

Key facts, with sources

• The median crash-free session rate across mobile apps in 2025 was 99.95%, with top-performing teams at the 75th percentile holding 99.99%. (Luciq Mobile App Stability Outlook 2025)
• Compared with JavaScriptCore, the Hermes engine cuts typical React Native app startup from about 4.5 seconds to about 2.0 seconds, memory from about 185 MB to 136 MB, and engine app-size overhead from about 12 MB to 8 MB. (OneUptime Blog)
• Real-world production migrations to React Native's New Architecture report around 43% faster cold starts, 39% faster rendering, and 26% lower memory usage. (RapidNative)
• Shopify's performance bar for its React Native apps is critical screens loading in under 500 milliseconds at the 75th percentile, alongside over 99.9% crash-free sessions. (Shopify Engineering)
• Published optimization case studies include Discord cutting app startup time in half and Coinbase reporting an 80% funnel performance improvement after its React Native rewrite. (CatDoes)

Prove the leak exists before hunting it

The first step is establishing that memory growth is a leak and not normal behavior — caches filling, images decoding, navigation state accumulating by design. My standard repro: pick one flow, typically open a detail screen and go back, and repeat it ten to twenty times while watching memory in the platform profiler. Healthy apps sawtooth: memory rises, garbage collection reclaims it, the baseline stays flat. Leaking apps staircase upward and never come back down.

Run this in a release or profiling build. Debug builds keep extra structures alive for the debugger and dev tools, producing phantom leaks that evaporate in production — I have watched teams burn days chasing memory that only leaked under the dev server.

The usual suspects in JavaScript

Nearly every JS-side leak I find in audits comes from a subscription that outlives its screen. Event listeners registered in useEffect without a cleanup return, intervals and timeouts never cleared, store subscriptions created imperatively, WebSocket or emitter handlers added on mount and forgotten, and in-flight network requests whose callbacks retain the unmounted component. Each of these holds a closure, and that closure holds the screen's props, state, and often its entire subtree.

Module-level caches are the second family: a map keyed by ID that grows forever, memoization without eviction, or an analytics queue that never drains. These are not lexical leaks — they are unbounded data structures — but they kill the app just the same, and heap snapshots expose them as ever-growing arrays and maps.

useEffect(() => {
  const controller = new AbortController();
  const sub = AppState.addEventListener('change', handleAppState);
  const timer = setInterval(refreshBadge, 30_000);

  fetch(endpoint, { signal: controller.signal })
    .then((res) => res.json())
    .then(setData)
    .catch(() => {}); // aborts land here

  return () => {
    controller.abort();
    sub.remove();
    clearInterval(timer);
  };
}, [endpoint]);

Heap snapshots with the Hermes debugger

React Native DevTools exposes Hermes heap snapshots, and the workflow that finds leaks fastest is the three-snapshot diff. Snapshot one at a clean baseline. Perform the suspect flow several times, force garbage collection if the tooling offers it, then snapshot two. Perform the flow several more times and take snapshot three. Objects allocated after snapshot one and still alive in snapshot three — especially ones whose count scales with your repetitions — are your leak candidates.

Filter for your own component and screen names first; five retained instances of a detail screen after five visits is a smoking gun. Then read the retainer chain: the path from the leaked object back to a GC root names the exact listener, timer, or cache holding it. Fix that reference, re-run the same diff, and confirm the count drops to one or zero.

Native leaks need native tools

When JS heap stays flat but process memory climbs, the leak lives on the native side — often in image handling, camera or map modules, or custom native code holding views, contexts, or listener references past their lifetime. On iOS, Xcode Instruments is the tool: the Allocations instrument with generation marking mirrors the snapshot-diff workflow, and the Leaks instrument flags unreachable-but-unreleased objects, commonly caused by retain cycles in blocks or delegates.

On Android, the Android Studio memory profiler captures native and Java heap dumps, and adding LeakCanary to debug builds gives automatic detection of leaked activities and fragments with the retaining chain spelled out. In React Native apps specifically, I pay attention to modules holding a reference to an Activity or view after teardown — a classic pattern in hastily written native modules.

Patterns that keep leaks from coming back

Fixing one leak is a bug fix; preventing the class of bug is architecture. I push teams toward a few conventions. Every effect that acquires a resource returns a cleanup releasing it — reviewers reject effects that subscribe without unsubscribing. Long-lived caches get explicit bounds: max entries, TTLs, or eviction tied to memory warnings. Event buses and singletons expose subscribe functions that return an unsubscribe handle, making cleanup impossible to forget silently.

Then make regressions visible: track memory in production monitoring alongside crashes, and add a soak test to the release checklist — drive the top three flows repeatedly and assert memory returns to baseline. Out-of-memory kills often report as generic crashes or silent restarts, so without deliberate measurement, leaks hide in your crash-free-rate blind spot.

When to hire senior help

Bring in a senior performance specialist when your crash-free rate sits below roughly 99.9%, startup exceeds a couple of seconds on mid-range Android, or the team lacks profiling experience with Hermes, the JS thread, and native tooling. Performance rescue work is diagnostic in nature, so a short expert engagement typically finds the handful of hot spots that in-house teams spend months guessing at. If your stack includes React Native + Python + AI, a senior engineer who owns the full product beats coordinating multiple juniors.

Bottom line

Dhairya Senjaliya ships Mobile — App Performance Optimization projects worldwide — book a scoping call to discuss your specific situation.

Common pitfalls to avoid

• ✕Profiling only on high-end iPhones in dev mode, then discovering the real user base on low-end Android devices experiences multi-second startups and dropped frames
• ✕Rendering long feeds with ScrollView or an untuned FlatList instead of a virtualized list like FlashList, blocking the JS thread during scroll
• ✕Passing new inline functions and object literals on every render without memoization, causing cascading re-renders that never show up until lists grow
• ✕Ignoring JS bundle size and startup path, shipping no lazy loading or inline requires, so time-to-interactive balloons as the app grows

Frequently asked questions

Sources

• Luciq Mobile App Stability Outlook 2025
• OneUptime Blog
• RapidNative
• Shopify Engineering
• CatDoes