Diagnosing and Fixing Memory Leaks in Rork-Generated React Native Code with Flipper and Instruments

Visualizing Memory Usage with Flipper

The first step is confirming a leak exists. Guessing and patching code at random is not a good use of time.

Step 1: Setting Up Flipper (requires macOS)

# Download and install Flipper from https://fbflipper.com/
# Connect via a development build, not EAS
 
npx expo start --dev-client
 
# Launch the Flipper Desktop app, then connect the simulator or a physical device
# If auto-detection fails, add the device manually via "+ Add Device"

Open both the "React DevTools → Profiler" tab and the "Memory" tab in Flipper before starting any measurements.

Step 2: Run a Repeatable Measurement Protocol

A repeatable protocol is what makes leak fixes comparable. The "leak regression test" I run is:

1. Launch the app and idle on the home screen for 10 seconds
2. In the Memory tab, click "Force GC" to capture a baseline
3. Open the target screen → navigate back, repeated 10 times (3–5 seconds per round-trip)
4. Click "Force GC" again at the end
5. Record the delta between baseline and final heap size

Inserting Force GC at both ends is critical. Without it, garbage-collection-pending objects look like leaks, and you'll waste twice the time chasing false positives.

Step 3: Reading the Numbers

In the Memory tab:

• Heap Size: Use the thresholds above. >5MB delta over 10 round-trips means block the release
• Retained Size: If a particular component is much larger than the others, that's your suspect
• GC Roots count: If this keeps climbing, listener cleanup is almost certainly missing

A clean, leak-free app should return to roughly its starting heap size after the protocol. If it doesn't, something is holding on to memory it should have released.

The Five Most Common Patterns (and How to Fix Them)

Pattern 1: Missing useEffect Cleanup

By far the most frequent issue in Rork-generated code. In my own audits, when I review 5 screens of Rork output, 3 of them have this pattern somewhere.

// ❌ Leaks memory — no cleanup function
useEffect(() => {
  const subscription = someEventEmitter.addListener('update', handleUpdate);
  // This subscription outlives the component
}, []);
 
// ✅ Fixed — cleanup function returned
useEffect(() => {
  const subscription = someEventEmitter.addListener('update', handleUpdate);
  return () => {
    subscription.remove(); // Runs when the component unmounts
  };
}, []);

When I ask Rork to fix this for me, I recommend the prompt "Add cleanup functions to all useEffect event listeners, but do not change the dependency arrays." Letting Rork modify the dependency arrays can introduce subtle re-render bugs in unrelated parts of the screen.

Pattern 2: Timer Not Cleared on Unmount

Common whenever you implement polling or delayed actions.

// ❌ Timer keeps firing after the screen is gone
useEffect(() => {
  const timer = setInterval(() => {
    fetchLatestData();
  }, 5000);
  // Nothing stops this timer when the component unmounts
}, []);
 
// ✅ Fixed
useEffect(() => {
  const timer = setInterval(() => {
    fetchLatestData();
  }, 5000);
  return () => clearInterval(timer);
}, []);

setTimeout follows the same rule: return () => clearTimeout(timer) in the cleanup. One trap to watch for: if you're using requestAnimationFrame in a loop (common for wallpaper-preview animations), make sure you also call cancelAnimationFrame(frameId) in the cleanup. This one bit me multiple times on the wallpaper app.

Pattern 3: State Updates After Unmount

If an API call or async operation finishes after the user has already left the screen, the callback will try to write to state in an unmounted component. React 18 stopped showing the console warning for this, but the wasted computation is still real.

// ✅ isMounted flag pattern — simple and readable
useEffect(() => {
  let isMounted = true;
 
  const fetchData = async () => {
    const result = await api.getItems();
    if (isMounted) {
      setItems(result);
    }
  };
 
  fetchData();
  return () => {
    isMounted = false;
  };
}, []);

You can also use AbortController, but the isMounted flag is easier to slot into existing Rork output without restructuring anything. In my experience, asking Rork to "protect async operations with the isMounted pattern" has a higher success rate than asking it to introduce an AbortController.

Pattern 4: Supabase / Firebase / RevenueCat Subscriptions

Real-time and billing features are particularly prone to this. The moment a Rork template wires up Supabase, it's worth running the check.

// ❌ Supabase realtime subscription stays active after unmount
useEffect(() => {
  const channel = supabase
    .channel('messages')
    .on('postgres_changes', { event: '*', schema: 'public', table: 'messages' }, handleChange)
    .subscribe();
  // No cleanup
}, []);
 
// ✅ Fixed
useEffect(() => {
  const channel = supabase
    .channel('messages')
    .on('postgres_changes', { event: '*', schema: 'public', table: 'messages' }, handleChange)
    .subscribe();
  return () => {
    supabase.removeChannel(channel);
  };
}, []);

RevenueCat's customer-info listener has the same issue. If you register with Purchases.addCustomerInfoUpdateListener, you must remove it with Purchases.removeCustomerInfoUpdateListener. On one of my apps, leaving this in place added 4MB of monotonic heap growth per month.

// ✅ RevenueCat listener cleanup pattern
useEffect(() => {
  const handler = (info: CustomerInfo) => {
    setIsPro(info.entitlements.active['pro'] !== undefined);
  };
  Purchases.addCustomerInfoUpdateListener(handler);
  return () => {
    Purchases.removeCustomerInfoUpdateListener(handler);
  };
}, []);

Pattern 5: FlashList Key Collision After Migrating from FlatList

Strictly speaking this isn't a leak, but after switching from FlatList to FlashList you can see sudden heap spikes. FlashList recycles cells internally, so if keyExtractor returns a non-unique key, the same cell is retained multiple times and memory piles up.

// ❌ Duplicate IDs cause heap growth
<FlashList
  data={items}
  keyExtractor={(item) => item.userId} // Duplicates when one user has multiple items
  estimatedItemSize={80}
  renderItem={renderItem}
/>
 
// ✅ Compound key guarantees uniqueness
<FlashList
  data={items}
  keyExtractor={(item) => `${item.userId}-${item.timestamp}`}
  estimatedItemSize={80}
  renderItem={renderItem}
/>

Keeping estimatedItemSize close to the median actual size (within ±5pt) is also important. Rork's default of 100 is rarely a good fit; tightening this gives the heap a noticeably steadier baseline.

Going Deeper with Xcode Instruments (iOS)

Once you've confirmed a leak with Flipper, Instruments gives you a richer picture on the iOS side.

Step 1: Launch and Configure Instruments

# With Rork Max, you already have a generated Xcode project
# Open .xcworkspace in Xcode
# Product → Profile (Cmd + I) → choose the Leaks template
# After launch, click "+" in the bottom-left and add the Allocations template

Pairing Leaks with Allocations lets you track not just true leaks but also "lingering memory" — objects that still have valid references but should have been released. These don't trip the Leaks detector but cause real damage in production.

Step 2: Operational Protocol

Run the same 10-round-trip test under Instruments. After each round-trip, press "Mark Generation" (the flag icon) — this lets you see, generation by generation, which class instances are accumulating.

If a particular class count keeps climbing across generations, that's where your leak lives. On one of my apps, UIView subclasses were accumulating 3–5 per round-trip; the cause was a code path that wasn't calling removeFromSuperview.

Step 3: Interpreting Results and Next Actions

Instruments has a steeper learning curve than Flipper, but it tells you both "which object is not being released" and "where the references are still held." Use it whenever Flipper confirms a leak exists but can't pinpoint the cause.

Verifying Your Fixes

After making changes, always verify them with the same method:

1. Connect Flipper
2. Run the "leak regression test" protocol (Force GC → 10 round-trips → Force GC)
3. Confirm the Heap Size delta is under 3MB
4. On iOS, optionally run the Generations check in Instruments
5. As a final pre-submission check, run a 30-minute continuous-use test on a real device

If the heap returns to baseline, you're done. If it's still climbing, there's likely another instance of the same pattern elsewhere. You can ask Rork to scan the entire file: "Check all useEffect hooks in this file and add cleanup functions wherever they're missing. Only check — do not modify hooks I haven't asked you to."

A Prompt Template for Rork

If you'd rather have Rork handle the fixes directly, here's the prompt I use in production:

Review this file for memory leaks and fix all of the following:
- useEffect hooks that register event listeners without returning a cleanup function
- setInterval / setTimeout calls that aren't cleared on unmount
- requestAnimationFrame loops that aren't cancelled
- Supabase / Firebase realtime subscriptions that aren't unsubscribed
- RevenueCat addCustomerInfoUpdateListener that isn't removed
- FlashList keyExtractor returning non-unique values
- Async operations that might update state after the component unmounts

Constraints:
- Do not modify existing dependency arrays
- Prefer the isMounted flag pattern for async protection
- After fixing, list every change and the reason for it

Pair this prompt with a specific file path (e.g., src/screens/ChatScreen.tsx). One file at a time produces noticeably fewer misses than batching multiple files into a single request.

Impact on eCPM and Retention

Leaving leaks unaddressed isn't just a technical hygiene issue — it directly affects revenue. Here are the actual before/after numbers from the wallpaper app I mentioned earlier:

• D1 retention: 38% → 41% (+3pt)
• D7 retention: 11% → 13% (+2pt)
• Average session length: 2m10s → 2m45s (+27%)
• AdMob eCPM: $4.20 → $5.15 (+22%)
• Monthly revenue: ~$6,500 → ~$8,000 (+22%)

AdMob tends to lower eCPM for apps with high short-session churn, because the auction algorithm reads "showing an ad doesn't lead to clicks or future sessions" as a signal to pay less. Retention loss and eCPM loss move together. Fixing leaks is a quality improvement and a revenue strategy.

Building the Habit Early

Memory leaks are much easier to prevent than to fix after the fact. A few habits to build into the Rork workflow:

• Whenever you see a useEffect, immediately ask whether it needs a cleanup function
• Treat any timer (setInterval, setTimeout, requestAnimationFrame) as automatically requiring a clear / cancel
• Assume any external subscription (Supabase, Firebase, WebSocket, RevenueCat) needs an explicit unsubscribe
• Use compound keys in FlashList keyExtractor to guarantee uniqueness
• After changing a key screen, run the "10 round-trips + Force GC" test in Flipper as a baseline check
• Insert one Instruments Generations check before App Store / Play submission

Across 50M lifetime downloads of personal apps, I keep coming back to the same lesson: taking memory hygiene seriously from day one cuts later operational cost by more than half. Apps that handle memory well feel noticeably snappier over long sessions — and users notice. Knowing how to diagnose and fix leaks means that when "the app gets slow" reports start coming in, you have a repeatable process instead of a guessing game.

If you want to go further, two related guides are worth bookmarking: Rork App Slow Performance Troubleshooting and Fixing React Native Build Errors in Rork Projects both cover complementary performance topics.

Start by running a quick search for useEffect in your codebase and checking each one for a missing cleanup. There's a reasonable chance you'll find one or two right away.