React Native debugger: Setup, config & troubleshooting guide

What is React Native debugger, and when should you use it?

React Native Debugger (RNDebugger) is a standalone Electron app that bundles Redux DevTools and a React Inspector into one window for debugging React Native apps. Which tool actually earns its place depends on the JS engine running underneath.

The Hermes engine changed how breakpoints attach and how stack traces resolve back to source, and that shift is the reason RNDebugger's value now varies by project rather than being a default pick.

That variability matters because debugger choice is just one piece of the broader React Native tech stack decisions teams make throughout a project.

Our engineers have traced Redux state in RNDebugger, debugged a Hermes source-map mismatch after a React Native upgrade, and shipped launch.json configurations on live client iOS and Android apps. That experience shapes when we reach for RNDebugger versus React Native DevTools, the official successor Meta now ships directly inside Metro.

Meta began deprecating Flipper's React Native integration back in version 0.73 (December 2023) and removed it from the default template in 0.74, per the React Native release notes, well before React Native DevTools shipped as the stable replacement in 0.76 (October 2024). That gap leaves RNDebugger as the pragmatic choice for legacy Redux-heavy codebases already wired for the Chrome DevTools protocol.

This guide covers setup for both, the tradeoffs teams argue about on Reddit, and the launch.json configs we run in production. choosing the right editor matters too, since your IDE's built-in debugging support can shape which of these tools fits best into your workflow.

How to install React Native debugger (Homebrew and manual)

Homebrew is the faster path on macOS and it keeps RNDebugger current without you tracking GitHub releases by hand.

brew install --cask react-native-debugger

That pulls the latest tagged build from jhen0409/react-native-debugger, installs the standalone Electron app into /Applications, and registers it as a debugger target Metro bundler can attach to over the Chrome DevTools protocol.

For Windows or Linux, or if you need to pin an older version to match a teammate's setup, grab the.dmg,.exe, or.deb directly from the GitHub releases page and install manually. Version pinning matters here: RNDebugger releases lag behind React Native's own DevTools and engine changes, so an app built against a recent Hermes upgrade can silently mismatch an old RNDebugger build.

Once it's installed, launch the app first, then start Metro and open your app so the packager's debugger menu can find the open RNDebugger window on its default port.

A Hermes engine bump can break this handshake entirely: RNDebugger reports a source-map mismatch, and stack traces point at minified bundle output instead of source, a caveat worth checking before you assume the install is broken.

How do you open React Native DevTools?

React Native DevTools opens by pressing j in the Metro terminal, or by selecting "Open DevTools" from the in-app Dev Menu (Cmd+D on iOS simulator, Cmd+M on Android emulator). No separate install, no Flipper plugin registration.

This is the newer built-in inspector, not RNDebugger. React Native 0.76 shipped React Native DevTools as the stable default, replacing the Chrome-based remote debugger and most of what Flipper covered. It runs on the Chrome DevTools protocol directly against the Hermes engine, which is the detail most guides skip.

If you're still building foundational knowledge alongside these tools, a few solid React Native reference books can help fill in the gaps DevTools won't explain.

Hermes exposes its own CDP-compatible inspector, so React Native DevTools attaches to the same runtime executing your app rather than a JS context running in a browser tab.

That's why breakpoints now hit accurately in production-shaped bundles, but it's also why we've seen source-map mismatches surface right after a Hermes version bump in an RN upgrade: the debugger attaches fine, but stack traces resolve to the wrong line until you rebuild the map.

The console and network tabs behave like standard Chrome DevTools, with a Redux tab appearing automatically if redux-devtools-extension is present. No separate window juggling, unlike RNDebugger's standalone Electron app.

For error and warning triage, LogBox notifications still route through the Dev Menu, and a full reload from that same menu resets the attach state if the inspector desyncs after a hot refresh.

Opening the dev menu on iOS and Android

The Dev Menu opens with Cmd+D on the iOS simulator and Cmd+M (Ctrl+M on Windows) on the Android emulator. It surfaces reload, refresh, and inspector options over the running app.

On a physical device, shake the phone using a firm flick, not a gentle wobble, to trigger the same menu; a soft shake often does nothing and gets mistaken for a broken build.

Expo Go handles the Dev Menu differently. Shake the device or press "m" in the Metro terminal window, per Expo's debugging documentation. Older SDKs show a plainer menu without the React Native DevTools entry, since the underlying react-native version, not the Expo wrapper, decides what the menu exposes.

Older Expo SDKs can show this gap: no DevTools option in the Dev Menu, no console notification when Metro reconnects, and a LogBox error that looks like a crash but is just a stale menu render. Bumping the SDK resolves it, confirming that Dev Menu content varies by SDK version, not just by trigger.

Redux DevTools and react inspector setup

React Native Debugger (RNDebugger) bundles Redux DevTools integration and a React Inspector into one Electron window, so state and component tree inspection sit side by side instead of split across browser tabs.

Install the standalone app from the jhen0409/react-native-debugger rather than the npm wrapper, the standalone build ships its own Electron shell and avoids version drift between a project's React DevTools version and RNDebugger's bundled version. If RNDebugger doesn't fit your workflow, it's worth weighing it against the broader debugging toolkit options available for React Native projects.

Open it before launching Metro, then select "Debug" from the Dev Menu; RNDebugger attaches and the Redux tab populates automatically if your store uses the standard redux-devtools-extension compose call.

The React Inspector tab mirrors the component tree with props and hooks state, refreshing on every reload without a manual reconnect.

One caveat worth flagging: Redux DevTools integration in RNDebugger only sees actions dispatched after the debugger attaches, so an error thrown during app boot, before the store connects, won't show in the action log.

For boot-time state bugs, add a console.log at the reducer's initial state instead of trusting the panel to catch it.

Flipper offered a similar Redux plugin, but its React Native support has been winding down since Meta's 2023 deprecation notice, which is the main reason teams still standardize on RNDebugger for this workflow.

Debugging with VS Code and launch.json

VS Code attaches to a running React Native app through the Chrome DevTools protocol, using a launch.json configuration that points at the Metro packager port and the target platform. This is the setup we reach for on client projects where the team wants breakpoints inside VS Code instead of a separate debugger window.

A typical .vscode/launch.json for a dual-platform app defines three configurations: Debug Android, Debug iOS, and Attach to packager. Each one sets "request": "attach", points "port" at Metro's default 8081, and needs a sourceMaps flag set to true so stack traces resolve back to your TypeScript or JSX, not the bundled output.

Source maps are where this setup breaks under Hermes.

JSC and Hermes generate bundles differently, and after a React Native upgrade the compiled Hermes bytecode bundle can ship without a matching source map, leaving VS Code stopped on a breakpoint that maps to the wrong line, or nothing at all.

The fix is confirming hermesEnabled and your Metro source-map output path align before you debug, not after.

According to the React Native debugging docs, the officially supported path since Flipper's deprecation is React Native DevTools, built on the Chrome DevTools protocol, with VS Code attach as the IDE-native alternative for teams that live in breakpoints rather than a standalone inspector window.

We recommend VS Code attach specifically when your team already debugs backend Node services the same way, since the muscle memory transfers directly.

IOS simulator, iOS device, Android, and attach to packager configs

Four launch.json configuration blocks cover the targets we hit most often on client builds, each pointing at a different Metro bundler port or platform flag.

iOS Simulator

{
 "name": "Debug iOS",
 "type": "reactnative",
 "request": "launch",
 "platform": "ios"
}

iOS Device (needs a device-specific target and a reachable Metro host):

{
 "name": "Debug iOS Device",
 "type": "reactnative",
 "request": "launch",
 "platform": "ios",
 "target": "device"
}

If debugging on physical devices becomes too time-consuming for your team, our React Native experts can help you build and maintain your app.

Android

{
 "name": "Debug Android",
 "type": "reactnative",
 "request": "launch",
 "platform": "android"
}

Attach to Packager, no launch step, just attaches to a running Metro instance on 8081, our default for a device already booted from a terminal npx react-native start session:

{
 "name": "Attach to packager",
 "type": "reactnative",
 "request": "attach"
}

Swap ports in the android block when Metro runs on anything other than 8081.

Which debugging tool should you use? Flipper vs reactotron vs RNDebugger vs DevTools

React Native DevTools is the right default for anything built on the Hermes engine after RN 0.74. RNDebugger fits teams that already depend on a Redux DevTools integration and still ship on JSC, Reactotron wins for network and async-storage tracing, and Flipper is now a legacy option, not a starting point.

Meta stopped bundling Flipper by default starting with React Native 0.74, according to the React Native release notes, moving the official debugging path to React Native DevTools, which runs on the Chrome DevTools protocol instead of Flipper's plugin bridge. Flipper still runs if you wire it in by hand, but its inspector plugins increasingly break against newer Hermes builds.

At Netguru, we still reach for RNDebugger on maintenance projects with an established Redux state shape and older JSC targets, since re-platforming a mature app's debug setup costs more than it saves.

On greenfield Hermes builds, we default straight to React Native DevTools and treat Reactotron as the add-on for API tracing that DevTools' console alone doesn't cover. These are the debugging conventions our React Native development team follows to keep engineering velocity high across both legacy and greenfield projects.

How to stop or disable React Native debugger

Stopping React Native Debugger takes two separate steps: quit the app itself, then turn off the remote debug flag in the Dev Menu. Skipping the second is the usual reason a rebuilt app still tries to attach to Chrome DevTools protocol on next launch.

First, close the standalone Electron-based RNDebugger window itself, the same way you'd quit any desktop app.

Second, open the Dev Menu (shake the device, or Cmd+D on iOS simulator / Cmd+M on Android emulator) and toggle off "Debug Remote JS." On Hermes builds this option is often replaced or grayed out entirely, since Hermes debugs over the Chrome DevTools protocol directly rather than through the remote JS bridge RNDebugger depends on.

Reload the app after toggling; a stale flag can leave the bundle waiting on a debugger socket that never connects, which shows up as a silent freeze rather than a console error.

Flipper support was removed from the default React Native template starting with version 0.74, per Meta's React Native GitHub release notes, so teams migrating off Flipper should confirm no lingering Flipper plugin config is also triggering a remote connection attempt on startup.

Fixing debugger connection issues (Ports, disconnects, hermes mismatches)

Most connection failures trace to one of three causes: a port already bound by a stale Metro bundler instance, a WebSocket handshake left over from a previous debug session, or a Hermes engine source map that no longer lines up with the running bundle.

Port conflicts are the easiest fix.

Metro bundler defaults to 8081; if RNDebugger won't attach, check whether another Metro process (or a second RN project) already owns that socket, then restart with react-native start --port 8088 and update the debugger's connection settings to match, per React Native's official debugging docs.

A stuck "Debugger disconnected" notification in the Dev Menu almost always means Metro was killed but the app didn't reload, force a reload from the menu rather than reopening the debugger window.

Hermes mismatches are trickier and less obvious. Because Hermes compiles JavaScript to bytecode ahead of time instead of interpreting it live like JSC, the debugger attaches to bytecode positions mapped back to source through a generated source map, if that map is stale, breakpoints land on the wrong line or don't bind at all.

This exact issue shows up after bumping RN minor versions without clearing the Metro cache; --reset-cache and a clean rebuild resolves it.

Meta's React Native release notes confirm Flipper's integration was deprecated in 0.73 (2023) and dropped from the default template in 0.74, which is why teams increasingly reach for React Native DevTools or RNDebugger over Flipper for this class of bug.

LogBox, performance monitor, and other lightweight diagnostics

LogBox separates fatal errors from warnings by default, and that split matters more than most teams realize.

A syntax error or unhandled exception takes over the full screen and halts the app; a deprecation warning surfaces as a dismissible banner you can disable per rule with LogBox.ignoreLogs.

That filter mutes noisy third-party warnings (certain Reanimated version mismatches, for example) without losing visibility on real crashes, per React Native's official debugging docs.

For performance, the in-app Performance Monitor overlay (shake gesture or Dev Menu) gives a live JS frame rate and UI frame rate reading, useful for catching a dropped-frame regression before it ships, though it won't replace a proper Flipper or Chrome DevTools CPU profile for root-causing jank.

Neither tool covers production. For that, wiring Sentry into the same build means a Hermes stack trace that never touches a developer's machine still lands with symbolicated context and breadcrumbs.

FAQ: React Native debugger setup and troubleshooting