Guide · Updated July 2026

React Native Debugging, the Practical Guide

React Native debugging used to be a graveyard of tools — the Chrome remote debugger, Flipper, a rotating cast of community inspectors. That era is over. Since React Native 0.76, there is one first-party debugger: React Native DevTools, built on Chrome DevTools, attached directly to the Hermes engine running your actual app. Remote JS debugging is gone, Flipper is no longer the recommended path, and everything worth learning lives in one place (checked July 2026).

This guide covers the tools in the order you'll actually reach for them — DevTools, native logs, real devices — and ends with the part the tooling doesn't solve: getting what you see on the device back into your codebase as a fix.

React Native DevTools: the debugger you'll actually use

Two ways to open it, with your app running in development:

• Press j in the terminal running Metro (or npx expo start).
• Or open the in-app dev menu — Cmd+D in the iOS Simulator, Cmd+M on the Android emulator, shake on a physical device — and choose Open DevTools.

What you get is real Chrome DevTools pointed at your app:

• Console — logs, errors, and a live REPL into your running app.
• Sources — set breakpoints, step through code, and pause on exceptions. One well-placed breakpoint routinely replaces twenty console.log calls: you see every variable in scope at the moment things go wrong, instead of the three you thought to print.
• Components and Profiler — React DevTools built in. Inspect any mounted component's props and state, edit them live, and record renders to find what's re-rendering and why.
• Memory — heap snapshots for leak hunting.
• Network — request inspection, covered next.

DevTools requires Hermes, which has been the default engine for years — if you started your app any time recently, you have it.

Console and network inspection

Console output shows up both in DevTools and in the Metro terminal, so the cheap workflow still works. The step up is the Network panel: it records fetch, XMLHttpRequest, and image requests while DevTools is open — status codes, headers, response bodies, timing. As of React Native 0.83, network inspection is a first-class panel in core; Expo projects had a version of it earlier through Expo's dev tooling (checked July 2026).

The network panel resolves an entire class of bug in seconds: "is my API even being called, and what did it actually return?" Before blaming your rendering code, look at the response.

Native logs: Xcode and adb logcat

DevTools sees your JavaScript. Some failures happen below it — the app crashes before the bundle loads, a native module fails to initialize, a missing permission string kills a camera call. For those you need the native logs:

• iOS: run the app from Xcode and watch the console pane, or open the simulator's logs via the macOS Console app.
• Android: adb logcat *:S ReactNative:V ReactNativeJS:V filters the firehose down to React Native's own output; drop the filter when you're hunting a native crash.

The rule of thumb: a red error screen means JavaScript failed and DevTools has the story. A silent white screen or an instant crash means it never got that far — go native.

Symptom to tool

The bugs that only appear on real devices

Simulators lie by omission. A whole category of bug is invisible until the app runs on hardware:

• Layout and safe areas. Notches, the Dynamic Island, home indicators, Android cutouts, and keyboards that cover the exact input the user is typing into. Pixel-perfect in the simulator, broken on an actual phone.
• Permissions. Camera, photos, notifications, location — the prompts, the deny path, and the "user denied it three weeks ago" path. Simulators lack the hardware and rarely exercise the flows.
• Offline and flaky network. Your simulator inherits your desktop's Wi-Fi. Your users have elevators, parking garages, and one bar of LTE. Airplane mode on a real device finds bugs no simulator run ever will.
• Performance. Dev mode plus a desktop-class CPU hides everything. A list that scrolls smoothly in the simulator can stutter badly on a mid-range Android phone in release mode. Always profile on hardware.
• Lifecycle. Backgrounding, app switching, and the OS killing your app under memory pressure — then reviving it into a state you never tested.

This is why testing an Expo app is a ladder that ends on physical devices, and why TestFlight feedback exists at all: some bugs are only ever discovered on someone's actual phone.

Debugging with an AI agent

If you build with Claude Code, Codex, or Cursor, the agent is a genuinely good debugger — when you feed it evidence instead of vibes:

• Paste errors verbatim. The full stack trace, the logcat excerpt, the network response. Agents fix precisely-described bugs on the first pass far more often than paraphrased ones.
• Screenshot visual bugs. A screenshot with the broken element circled beats three paragraphs of description — "no, the other red box" is not a workflow. This is the core move of vibe debugging.
• Demand proof. Ask for before/after evidence, not "done". Then verify on the device yourself, because that's the one place the agent can't look.

That last point is the structural gap. Your agent can read every log and edit every file, but it cannot see the app running on your phone. It won't notice the button under the home indicator or the safe-area regression it just introduced. Someone has to carry what the device shows back into the codebase — and if your users won't do it (they won't), that someone is you.

Vibejar is that carry, automated: spot the bug in your own app, screenshot it, circle what's wrong, and it lands in your coding agent with full visual context. The agent ships the fix and sends back before/after proof — the loop from "spotted on device" to "fixed in code," closed.

For the rest of the tooling landscape — device clouds, E2E frameworks, crash reporters — see the mobile app testing tools roundup.

Frequently asked questions