React Native DevTools: debugging after Flipper

If you've been doing React Native for a few years, your debugging habits probably formed around tools that don't exist anymore. The old remote JS debugging in Chrome is gone, Flipper got dropped as the default, and React Native DevTools is now the built-in story. I held onto old habits longer than I should have, so this is the "here's how debugging actually works now" post I wish I'd read sooner.

Why the old way had to go#

The classic "Debug JS Remotely" approach ran your JavaScript in Chrome's V8 instead of on the device. That meant you were debugging in a different engine than production (which runs Hermes), with different timing and different behavior. It "worked," but it could hide bugs that only showed up in the real engine, and it was always a slightly false environment.

The move is to debug the JavaScript where it actually runs - on Hermes, on the device - using the proper tooling. That's what React Native DevTools does.

React Native DevTools, the new default#

Open the dev menu, choose to open DevTools, and you get a debugging experience built on the Chrome DevTools frontend but wired to the actual Hermes engine on your device or simulator. The things I use constantly:

• Breakpoints and stepping in your real JS, running on the real engine. Set a breakpoint, hit it, inspect scope, step through. No separate Chrome tab pretending to be your runtime.
• The console, attached to the actual app, with proper logging and evaluation in the running context.
• A React component inspector for walking the component tree, seeing props and state, and figuring out which component is rendering what.

The key difference from the old world is fidelity: you're looking at the genuine runtime, so what you see is what's actually happening.

How I actually debug, day to day#

Honestly, most debugging isn't fancy. My real workflow, in rough order of frequency:

1. Targeted logging. Still the fastest tool for "what's the value here, what order do these run in." Unfashionable, completely effective.
2. A breakpoint in DevTools when logging isn't enough and I need to inspect scope or step through logic. This is where running on the real engine matters - the state is real.
3. The component inspector when the bug is "why is this rendering / not rendering / re-rendering," to see the tree and props directly.
4. Native logs (adb logcat on Android, the Xcode console on iOS) when the problem is below JavaScript - a native crash, a permissions issue, something in a native module. The JS tools can't see these, and remembering to drop to the native logs saves a lot of confused staring.

The thing I had to consciously unlearn was reaching for the old Chrome remote debugging out of muscle memory. It's not the path anymore, and the replacement is genuinely better because it's honest about the runtime.

On Flipper#

Flipper was a big deal for a while - network inspection, layout inspection, plugins. With it dropped as the default, the question is what replaces those. Network inspection is available through the DevTools network panel; a lot of what people used Flipper for has been folded into the built-in tooling or has standalone alternatives. If you had a Flipper workflow you loved, the migration is real but the gaps are mostly filled. I don't miss maintaining the Flipper setup across upgrades, which was its own recurring chore.

The practical takeaway#

If your debugging habits predate the New Architecture, the upgrade worth making is mental: stop debugging in a fake Chrome runtime, start using React Native DevTools against the real Hermes engine. Keep logging for the quick stuff, use breakpoints when you need to inspect, lean on the component inspector for render mysteries, and drop to native logs the moment the problem smells like it's below JavaScript. It's less tooling to maintain than the Flipper era and more honest than the remote-Chrome era - which, after years of both, I'll take.