Finding and Fixing Memory Leaks in React Native Apps

1. Why Memory Leaks in React Native Are Particularly Tricky

React Native consists of at least two memory worlds that are managed separately: the JavaScript heap, cleaned up by the JavaScript engine's garbage collector, and native memory on iOS and Android, which works through reference counting or its own garbage collection. An object no longer needed on the JavaScript side can still stay in memory if a native component, say a map view or a video player, keeps holding a reference to it. This split makes memory leaks in React Native harder to diagnose than in pure web applications, because a single profiling tool rarely covers both sides at once.

What makes this particularly tricky is that many leaks only show up after repeated navigation: a single screen may look unremarkable when opened once, but if a user navigates back and forth between two screens ten times and memory usage keeps climbing instead of returning to a stable level after each back-navigation, that points to a systematic leak in screen creation or unmounting. This exact pattern, repeated navigation with continuously rising memory usage, is the most reliable first indicator, before even opening a profiling tool.

2. Cause 1: Unremoved Event Listeners

By far the most common cause of memory leaks in React Native apps is an event listener registered inside useEffect but never removed in the cleanup function. This affects native event emitters like AppState, Dimensions, NetInfo, or custom NativeEventEmitter instances just as much as listeners on third-party libraries. Any missing cleanup function returned from useEffect keeps the affected component alive in memory via the listener reference, even long after it has unmounted, because the native emitter still holds a callback reference to it.

This mistake compounds over time especially with libraries that use a global singleton emitter: every navigation to a screen registers a new listener without ever removing the old one, and after twenty navigation events, twenty stale callback functions run in parallel, each with its own reference chain back to its original component. A systematic review of every AppState.addEventListener, Dimensions.addEventListener, or DeviceEventEmitter.addListener call site in the code is therefore the first step of any leak diagnosis.

// Buggy: listener is never removed
useEffect(() => {
  const subscription = AppState.addEventListener("change", handleAppStateChange);
  // missing return -> leak on every mount/unmount cycle
}, []);

// Correct: cleanup function removes the listener on unmount
useEffect(() => {
  const subscription = AppState.addEventListener("change", handleAppStateChange);
  return () => {
    subscription.remove();
  };
}, []);

// Native event emitter with an explicit reference
useEffect(() => {
  const emitter = new NativeEventEmitter(NativeModules.LocationModule);
  const sub = emitter.addListener("onLocationUpdate", handleLocationUpdate);
  return () => {
    sub.remove();
  };
}, []);

3. Cause 2: Hanging Timers and Intervals

setTimeout and setInterval are a second frequent source of leaks, especially when a timer callback calls a state update function on a component that has already unmounted. Older React versions emit a warning for this pattern, and modern React versions suppress it, but the underlying memory problem remains: the timer holds a reference to the component and every variable it captured, via its callback, until it either expires or gets explicitly cleared.

The problem compounds particularly with setInterval, since an uncleared interval timer keeps running indefinitely and, on every tick, tries again to access a component that no longer exists, adding unnecessary CPU load on top. The reliable fix is to store every timer ID in a ref and consistently clean it up with clearTimeout or clearInterval inside the useEffect cleanup function, regardless of whether the timer has already fired by that point.

4. Cause 3: Closures That Reference Components

More subtle than missing listener cleanups are closures that unintentionally keep an entire component or a large object alive, even though only a small part of it is actually needed. A classic example is a callback stored outside a component in a module-level array or map, say to register a global handler, that retains access to props or local variables of the original component through the closure. As long as that entry in the global array is never explicitly removed, it prevents the garbage collector from releasing the entire referenced component along with its component tree.

Equally problematic are callbacks passed to native modules that get cached there in a native data structure, for example a camera callback that gets re-registered on every capture cycle but never deregistered. Since native modules are a black box from the JavaScript side, this leak stays invisible during a pure JavaScript heap analysis and only becomes visible in the native profiler, which is one of the main reasons a pure Chrome DevTools analysis often falls short for React Native memory leaks.

5. Diagnosing with Xcode Instruments on iOS

Xcode Instruments offers two complementary tools for iOS memory analysis: the Leaks template and the Allocations template. The Allocations template shows memory usage over time as a graph and lets you mark generations: you trigger an action, say opening and closing a screen ten times in a row, mark a generation before and after, and let Instruments show only the objects created between the two marks that were never released again. If objects clearly belonging to the screen under investigation consistently remain after several repetitions, there is a leak.

The Leaks template adds automatic detection of reference cycles in native Objective-C and Swift code, which in React Native apps often show up in custom native modules or in bridging code between JavaScript and native views. Also relevant for Hermes-based apps: the JavaScript heap itself needs to be examined through Hermes's own memory profiler, accessible via the Chrome DevTools connection or through Flipper; Instruments only shows native memory, not the internal JavaScript heap state.

# Start Xcode Instruments from the command line for a CI run
xcrun xctrace record --template "Leaks" \
  --device "iPhone 15 Simulator" \
  --launch -- /path/to/MyApp.app

# Open the resulting .trace file for further analysis in Instruments
open MyApp_*.trace

6. Diagnosing with the Android Studio Profiler

The Android Studio Memory Profiler shows a live graph of the Java heap, the native heap, and other memory categories, and lets you generate a heap dump at any point. The same approach that works for Instruments applies here: repeat an action multiple times, generate a heap dump before and after the repetitions, and compare the two dumps side by side. Objects whose count unexpectedly rose between the dumps, say instances of a specific component class or a bitmap object, give the decisive clue about where the leak originates.

A detail particularly relevant for React Native apps is the native heap, reported separately from the Java heap on Android, which often contains bitmap memory for images as well as the memory footprint of the JavaScript engine itself. A steadily growing native heap alongside a stable Java heap often points to unreleased image data, for instance when an image component loads large original images instead of already-scaled variants and caching them is left unbounded.

7. A Systematic Debugging Workflow for Memory Leaks

A reproducible workflow starts with isolation: instead of examining the entire app, first identify the specific screen or user flow where memory usage climbs, for example by deliberately watching the memory graph during typical navigation paths. Next comes repetition: run the same action at least five to ten times, since a single pass rarely distinguishes clearly between normal memory usage and a real leak, while a steadily rising trend over several repetitions is a clear signal.

The third step narrows things down with the matching native profiler, Instruments on iOS or Android Studio Profiler on Android, to identify the concrete object types that are not being released. The final step locates the cause in the code, usually through a targeted search for addEventListener, setInterval, or addListener calls in the affected screen, followed by repeating the entire workflow again after the fix to confirm that memory usage now genuinely stays stable.

8. Preventive Patterns: WeakMap, Refs, and AbortController

Beyond reactive debugging, it pays off to adopt patterns that make memory leaks harder to introduce in the first place. Using a WeakMap instead of a regular object or array for caches keyed by component instances lets the garbage collector automatically drop entries once the associated component is no longer referenced elsewhere. For callbacks passed to native modules, an AbortController pattern also works well, where a signal explicitly indicates whether a still-running asynchronous operation should even process its result anymore.

For timer and listener cleanup, a dedicated custom hook that encapsulates registration and removal is worth building, so the cleanup call does not need to be hand-written again for every single component and potentially forgotten. Such a hook centralizes correct behavior in one place and makes it easier for the whole team to structurally avoid memory leaks rather than discovering them first in the profiler.

// Custom hook encapsulates registration and guaranteed cleanup logic
function useAppStateListener(callback: (state: AppStateStatus) => void) {
  const callbackRef = useRef(callback);
  callbackRef.current = callback;

  useEffect(() => {
    const subscription = AppState.addEventListener("change", (state) => {
      callbackRef.current(state);
    });
    return () => subscription.remove();
  }, []);
}

// Usage: no manual cleanup needed, cannot be forgotten
function ProfileScreen() {
  useAppStateListener((state) => {
    if (state === "active") {
      refetchProfile();
    }
  });
  return <ProfileContent />;
}

9. Diagnosis Limits and Continuous Monitoring

Profiling sessions in Instruments or Android Studio Profiler reliably find leaks, but depend on manual test runs and rarely cover every user path of a real app. A leak that only shows up in a rarely used combination of screens easily stays undetected in local profiling until it becomes visible in production as a cluster of crashes. That is why continuous production memory monitoring, for example through native crash reporting tools with out-of-memory detection, meaningfully complements point-in-time local diagnosis.

It also matters not to confuse memory leaks with high but stable memory usage: an image gallery with many large images naturally consumes more memory than a simple form, and that is not a leak as long as usage drops again after leaving the screen. A leak only exists once memory usage keeps climbing after repeatedly leaving and re-entering the same state, instead of returning to a stable level.

10. Summary

11. FAQ: Finding Memory Leaks: The Essentials at a Glance