If you've upgraded React Native lately, you've probably noticed the network inspector you relied on is gone. Flipper was deprecated in React Native 0.73 and dropped from new app templates in 0.74. React Native DevTools took over in 0.76 — and it's good — but its Network panel only shows requests your JavaScript makes through fetch and XMLHttpRequest. The request your auth SDK fires, the analytics beacon, the image your CDN serves, the call a third-party native module makes — none of it shows up.
This guide fixes that. You'll route your React Native app's traffic through a local proxy on your Mac and see every request — JS-layer and native-layer — with full HTTPS decryption, across the iOS Simulator, the Android emulator, and physical devices.
The short answer
To debug React Native API requests on macOS: run a local HTTPS proxy (we'll use Rockxy, a free open-source native macOS debugger), trust its root certificate on the platform you're testing, point the app at the proxy, and read the decrypted requests. The iOS Simulator picks up your Mac's proxy automatically once the certificate is trusted. The Android emulator needs a proxy address and a small network_security_config.xml change so your debug build trusts user certificates. A physical device needs the same certificate plus a Wi-Fi proxy pointing at your Mac's IP.
Because you're capturing at the network layer, you see traffic from every source in the app — not just the calls your own JavaScript makes.
Why React Native traffic is hard to see
A React Native app is two worlds. Your JavaScript runs in Hermes. Your networking does not. When you call fetch, the request is handed down to the platform's native HTTP stack — NSURLSession on iOS, OkHttp on Android — and that's where it actually hits the wire.
That handoff is exactly why in-app inspectors are partial. They instrument the JS side, so they see the fetch you wrote. They don't see:
- Requests from native SDKs (Firebase, RevenueCat, Sentry, push providers).
- Analytics and crash-reporter beacons.
- Image loads from libraries like
react-native-fast-image. - Anything a native module does on its own thread.
A proxy sits one layer lower, at the OS network boundary. Every request from the app passes through it regardless of which world started it. One capture point, complete picture.
What React Native DevTools' Network panel actually shows
Worth being precise, because DevTools is the default now and it's genuinely useful for a lot of work:
- Shows:
fetchandXHRfrom your JS, with request/response headers and bodies, while the panel is open. - Misses: native-initiated traffic, traffic before the panel attaches, and anything outside the JS networking layer. It also resets on reload and can't rewrite or replay a request.
If your bug is "my fetch returns the wrong shape," DevTools may be all you need. If your bug is "the app works in the simulator but a real device gets a 401 from a service I don't directly call," you need to see the whole network. That's a proxy.
Prerequisites
- macOS with Rockxy installed.
- A React Native project (bare or Expo). Examples assume RN
0.74+. - Xcode (for the iOS Simulator) and/or Android Studio (for the emulator).
If you've never set up HTTPS interception on macOS before, the mechanics — per-host TLS certificates and a Keychain-stored root CA — are explained in How Rockxy Intercepts HTTPS Without Compromising Security. This post assumes the general flow from How to Debug HTTPS Traffic on macOS with a Local Proxy and applies it specifically to React Native.
For a runnable project, use Rockxy-ReactNative-Sample-Guidance. It is a bare RN 0.74+ app with buttons for a JS fetch, a native image load, and a native-module request, plus a local demo server — so you can see the JS-vs-native capture gap in one run. The React Native setup guide walks through the same trust and proxy steps for each runtime.
Step 1 — Start the proxy and trust the certificate
- Open Rockxy and enable the system proxy. It registers as your Mac's HTTP/HTTPS proxy and starts capturing immediately.
- Install and trust Rockxy's root certificate in the macOS Keychain. This lets it decrypt HTTPS for the hosts you choose, locally on your machine.
At this point traffic from Mac apps — and from the iOS Simulator, which shares your Mac's network stack — is already being captured. The emulator and physical devices need a couple of extra steps below.
Everything is decrypted and stored locally on your Mac. Nothing leaves the machine unless you explicitly export or share it.
fetch calls and the native-SDK requests an in-app inspector would miss.Step 2 — iOS Simulator
The iOS Simulator is the easy case because it uses your Mac's network and proxy settings directly.
- With the proxy running, install Rockxy's certificate into the Simulator and trust it. On iOS, certificate trust has two parts: install the profile, then enable full trust under Settings → General → About → Certificate Trust Settings. Forgetting the second toggle is the most common reason HTTPS still won't decrypt.
- Launch your app in the Simulator and trigger a request. It appears in Rockxy.
A quick way to prove the route end to end before you go hunting for the real bug:
// Drop this in a screen, tap once, then look in Rockxy.
fetch('https://httpbin.org/get?probe=rockxy')
.then((r) => r.json())
.then((d) => console.log('reached:', d.url))
.catch((e) => console.warn('blocked:', e.message));If that flow shows up decrypted, your Simulator setup is correct and any remaining gap is in the app, not the plumbing.
Step 3 — Android emulator
Android is where most people get stuck, for two reasons: the emulator doesn't inherit your Mac's proxy, and modern Android doesn't trust user-installed certificates for app traffic by default.
Point the emulator at the proxy. Set the proxy in the emulator's Settings → Proxy (manual configuration) to your Mac's address and Rockxy's port. From inside a standard Android emulator, your Mac's loopback is reachable as 10.0.2.2, so use that as the proxy host with Rockxy's port. Then install and trust Rockxy's certificate on the emulator.
Make your debug build trust the certificate. Since Android 7 (API 24), apps ignore user-added CAs unless they opt in. For a debug build, add a network security config so it accepts user certificates while debugging:
<!-- android/app/src/debug/res/xml/network_security_config.xml -->
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
<debug-overrides>
<trust-anchors>
<certificates src="user" />
<certificates src="system" />
</trust-anchors>
</debug-overrides>
</network-security-config>Reference it from your debug manifest only, so production is never affected:
<!-- android/app/src/debug/AndroidManifest.xml -->
<application
android:networkSecurityConfig="@xml/network_security_config" />Rebuild the debug app, trigger a request, and it shows up decrypted in Rockxy. Keeping this in src/debug/ means it ships nowhere near your release build.
Step 4 — Physical device
Real devices catch bugs simulators hide — different network paths, real certificate behavior, real timing.
- Put the device on the same Wi-Fi as your Mac.
- In the Wi-Fi network settings, set a manual HTTP proxy to your Mac's local IP and Rockxy's port.
- Install and trust Rockxy's certificate on the device (on iOS, the same two-part trust step from Step 2; on Android, the same network-security-config opt-in for your debug build).
- Trigger a request and watch it land.
Find your Mac's IP with ipconfig getifaddr en0 (Wi-Fi; try en1 if that's empty). That's the address the device's proxy setting needs.
This is the configuration that surfaces "works on my machine but not on the device" problems — the ones worth catching before users do.
Expo notes
- Expo Go runs your JS inside a prebuilt host app, so native config changes don't apply. The proxy approach still captures traffic once the certificate is trusted on the platform; for the Android network-security-config opt-in you'll want a development build (
expo run:androidor EAS dev client) rather than Expo Go. - Bare / prebuild workflows behave like a standard RN project — the steps above apply directly.
The same approach used for Flutter on the iOS Simulator and Android emulator carries over almost one-to-one; if you also work in Flutter, see How to Debug Flutter API Requests on macOS.
What you can do once the traffic is visible
Capturing is the start. The reason to inspect at the network layer is what you can do next:
- Read full request and response — headers, bodies, status, timing — for every call, JS or native.
- Rewrite on the fly — change a response to test how the app handles an error, an empty list, or a slow endpoint, without touching backend code.
- Set breakpoints — pause a request before it's sent or before the response reaches the app, edit it, and continue.
- Replay — re-send a captured request with modified headers or body to reproduce a bug or test an auth fix.
For the auth-token and header debugging that eats React Native time, being able to replay a request with a tweaked Authorization header turns a guessing game into a two-second check.
Common mistakes that waste time
iOS HTTPS still won't decrypt. You installed the certificate but skipped the trust toggle. Enable it under Settings → General → About → Certificate Trust Settings.
Android shows connection errors after adding the proxy. The emulator reaches the proxy but the app rejects the certificate. You're missing the network_security_config.xml opt-in for the debug build.
Nothing appears at all on Android. The emulator proxy isn't set — it doesn't inherit your Mac's proxy the way the iOS Simulator does.
Confusing Metro with the proxy. Metro's bundler port (8081) is unrelated to the proxy port. Pointing the device at 8081 won't capture API traffic.
A specific host won't decrypt. That service likely uses certificate pinning. Pinning intentionally rejects intercepting proxies; in a debug build you can disable the pinning library to inspect, then re-enable it.
You only see your own fetch calls and assume that's everything. That's the DevTools view. If a native SDK is involved, confirm in the proxy, where native traffic also appears.
Hand the captured traffic to your AI assistant
If you use Claude Desktop, Cursor, or another MCP-capable assistant, you can let it read the flows you just captured — list them, pull full request/response detail, and replay requests — without copy-pasting. Setup takes a few minutes: see How to Connect Claude Desktop to Rockxy's MCP Server.
Frequently asked questions
Can I inspect React Native network requests without Flipper?
Yes. Flipper was deprecated in RN 0.73 and removed from templates in 0.74. Route your app's traffic through a local proxy on your Mac to capture every request with full HTTPS decryption — including native-SDK traffic that in-app inspectors miss.
Does React Native DevTools show all network traffic?
No. Its Network panel shows fetch and XHR from your JavaScript while the panel is open. It doesn't show native-initiated requests (analytics, push, third-party SDKs) or traffic before the panel attaches. A system proxy captures all of it.
Why don't my requests show up on the Android emulator?
The emulator doesn't inherit your Mac's proxy — set it manually in the emulator settings. And since Android 7, debug builds must opt in to trusting user certificates via a network_security_config.xml. Both are required for HTTPS to appear.
Does the iOS Simulator need extra setup?
Only certificate trust. The Simulator uses your Mac's network and proxy automatically, so once Rockxy's certificate is installed and trusted, traffic is captured.
Will this work with Expo?
Yes, with a development build. Expo Go can't apply the native Android certificate config, so use expo run:android/EAS dev client for full HTTPS capture on Android. The iOS Simulator works once the certificate is trusted.
Wrap-up
The post-Flipper era left React Native developers with a partial network view. React Native DevTools handles JS-layer requests well, but the bugs that cost the most hours — native SDKs, auth tokens, device-only failures — live below that layer. A local proxy captures the whole network at one point, decrypts HTTPS locally, and lets you rewrite, breakpoint, and replay.
For the underlying HTTPS mechanics, read How to Debug HTTPS Traffic on macOS and How Rockxy Intercepts HTTPS Without Compromising Security. For other clients, the companion guides on Flutter and Node.js API debugging use the same capture workflow.
If you are setting this up for a team, start with the React Native setup guide and the sample repo. The same capture workflow applies whether the request comes from your JavaScript, a native image load, a third-party native SDK, or a custom native module.
