iOS Memory Pressure on Rork Apps — A 5-Tier Release Architecture from 12 Years of Wallpaper Apps

Receive on the React Native side — registering tier-specific handlers

The cleanest way to forward events from native to JS is to subclass RCTEventEmitter. Below is the TypeScript side that aggregates per-tier handlers. It slots directly into Rork's Expo Router output.

import { NativeEventEmitter, NativeModules } from 'react-native';
 
type Tier = 1 | 2 | 3 | 4 | 5;
 
interface MemoryEvent {
  tier: Tier;
  footprintMB: number;
}
 
type Handler = (event: MemoryEvent) => Promise<void> | void;
 
class MemoryPressureBus {
  private handlers = new Map<Tier, Set<Handler>>();
  private emitter: NativeEventEmitter;
 
  constructor() {
    this.emitter = new NativeEventEmitter(NativeModules.MemoryPressureManager);
    this.emitter.addListener('onMemoryPressure', this.handleNative);
    for (let t = 1; t <= 5; t++) {
      this.handlers.set(t as Tier, new Set());
    }
  }
 
  register(tier: Tier, handler: Handler): () => void {
    this.handlers.get(tier)?.add(handler);
    return () => this.handlers.get(tier)?.delete(handler);
  }
 
  private handleNative = async (event: MemoryEvent) => {
    // Fire all handlers for this tier in parallel.
    // A slow handler must never block others.
    const handlers = Array.from(this.handlers.get(event.tier) ?? []);
    await Promise.allSettled(handlers.map((h) => h(event)));
  };
}
 
export const memoryBus = new MemoryPressureBus();

Each screen and each cache layer registers itself with the tier that fits its risk profile. The image cache subscribes to Tiers 1 and 2, animations to Tier 3, ListView prefetch to Tier 4, and so on. Components just register and unregister inside a useEffect.

A cache-layer example — pairing with Expo Image

The single biggest practical win in my apps has been controlling the Expo Image memory cache. expo-image exposes Image.clearMemoryCache() to drop decoded bitmaps in one call, and just registering it at Tier 2 substantially reduced the number of warnings that escalated past Tier 1.

import { Image as ExpoImage } from 'expo-image';
import { memoryBus } from '@/lib/memoryBus';
 
// Call once at app launch.
export function registerImageCacheHandlers() {
  // Tier 1: disk cache (re-downloadable).
  memoryBus.register(1, async () => {
    await ExpoImage.clearDiskCache();
  });
 
  // Tier 2: decoded bitmaps in memory.
  memoryBus.register(2, async () => {
    await ExpoImage.clearMemoryCache();
  });
 
  // Tier 5: swap visible high-res to low-res.
  memoryBus.register(5, async () => {
    useLowResolutionFallback.getState().enable();
  });
}

Tier 5 is a heavy hammer, so I gate it carefully on the Swift side via currentFootprintMB. In my setup, Tier 5 fires only when foreground footprint exceeds 720MB. Computing the threshold dynamically from ProcessInfo.processInfo.physicalMemory is the safe move: 600MB on 4GB devices, 1.0GB on 6GB, and 1.4GB on 8GB devices.

Measurement flow with Instruments and MetricKit

None of this implementation matters without measurement on real devices. My division of labor is Instruments during development and MetricKit in production.

For the Instruments side during development:

1. Pick the device in Xcode, then Product → Profile → Allocations.
2. Script a typical user flow for the first 5 minutes after launch (scroll 50 wallpapers, favorite 20, bounce between settings 3 times).
3. Run VM Tracker alongside and record peak Resident Size.
4. Synthetically trigger memory warnings via xcrun simctl and verify that each tier releases as logged.
5. Capture screenshots showing Resident Size dropping after release as expected.

A caveat: Allocations only sees the Swift-side caches. The JS heap is invisible. If you're on Hermes, enable the Hermes sampling profiler via the react-native start flag and take a heap snapshot via Chrome DevTools separately.

In production I collect MetricKit's MXMetricPayload daily and stream it to BigQuery. The two signals I watch most are average footprint per cumulativeForegroundTime and MXAppLaunchMetric.histogrammedTimeToFirstDraw. After introducing Tier 2 release, the latter improved by 180ms at p95 — the kind of slow-burn UX improvement users notice without being able to name it.

import MetricKit
 
final class MetricsReporter: NSObject, MXMetricManagerSubscriber {
 
    func didReceive(_ payloads: [MXMetricPayload]) {
        for payload in payloads {
            guard let memory = payload.memoryMetrics else { continue }
            // Send averages and peaks to a Cloudflare Workers endpoint.
            // Always include device model, OS version, and app version.
            Task {
                await MetricsClient.shared.report(
                    averageMB: memory.averageSuspendedMemory.averageMeasurement.value / 1_048_576,
                    peakMB: memory.peakMemoryUsage.value / 1_048_576
                )
            }
        }
    }
}

The concrete path from 4.3% to 0.36% OOM rate

Here's the order in which I shipped the work and the OOM rate at each stage. I keep this record in Notion because I can never remember afterward which change was the real lever.

• Before any work (2025-11): OOM 4.3% / average Resident Size 540MB / Crashlytics has "OOM" at the top of the list
• After Tier 1 (disk cache): 4.1% — within noise. By itself, this is barely a Band-Aid
• After Tier 2 (decoded bitmaps): 2.4% — large improvement. The image cache was clearly the dominant factor
• After Tier 5 (low-res placeholder swap): 0.9% — big drop on 4GB devices
• After Tier 3 & 4 (animation buffers and adjacent prefetch): 0.36% — iPad mini 6 numbers finally cleaned up

The whole effort took about 3 weeks, but roughly 70% of the benefit came from Tier 2 alone. If you're an indie developer with limited time, my recommendation is to start with Tiers 1 and 2 together. Tiers 3 through 5 vary by device and usage pattern, so it's worth watching MetricKit numbers before investing the time.

Specifics for Rork-built projects

If you ship the Expo project that Rork outputs straight through EAS, Hermes is enabled by default. Hermes keeps the JS heap relatively small, but native-side caches are a separate concern, so this design still applies as is.

Two caveats to keep in mind. First, modules like Expo Image Picker and Camera that temporarily allocate large buffers expose their own release APIs (releasePreviewBuffers and similar). Register those at Tier 3 or 4; by default they hold onto memory and won't release on warning automatically.

Second, the Expo Modules threading model. An @objc(MemoryPressureManager) class instance is initialized on the main thread by default. NotificationCenter.default.addObserver must be called on the main thread anyway, so the code above is fine. But the JS event emitter dispatched from escalateRelease runs on the JS thread, so any work that needs hard real-time on the native side (such as releasing audio buffers) should stay on the Swift side end-to-end.

Next steps

When adopting this design in your own app, I recommend the following order.

1. Add a single native module that subscribes to UIApplication.didReceiveMemoryWarningNotification.
2. Set up memoryBus on the JS side and start with just the Expo Image Tier 1/2 registration.
3. Measure OOM rate before and after with Instruments to confirm the effect.
4. Add MetricKit so you can observe production memory peaks on a daily cadence.
5. Then layer in your app's specific cache layers (API responses, map tiles, audio) at Tiers 3 and 4.

Thanks for reading. I hope it helps you stabilize your own Rork-built apps.