skip to content

DevTools Inspector

React Native DevTools attaches Chrome's DevTools frontend to Hermes for console, breakpoints and network requests, plus the component tree. Interviewers ask what replaced Flipper and remote debugging.

part ofReact Nativeoverview, primer and where to startread it →
on this pageshow

explore

questions

4

In a React Native 0.87 app, how do you open React Native DevTools, and what do its main panels let you do?

level: juniorimportance: must knowfreq 62%

answer

  1. one keypress in the dev server terminal
  2. Dev Menu item: Open DevTools
  3. Chrome DevTools frontend, Hermes backend
  4. Console, Sources, Network, Components
  5. desktop app since 0.83

basics

~20 s

Press j in the dev server terminal or choose Open DevTools in the Dev Menu. React Native DevTools, a Chrome DevTools-based debugger attached to Hermes on the device, gives you Console, Sources with breakpoints, Network and React Components panels.

solid answer

~40 s

React Native DevTools is the built-in debugger and has been the default since 0.76. I open it by pressing `j` in the terminal where Metro is running (with several apps connected it asks which one to debug) or with **Open DevTools** in the Dev Menu. Since 0.83 it launches as a bundled desktop app, falling back to Chrome or Edge only if that binary can't be downloaded. It speaks the Chrome DevTools Protocol to the Hermes runtime on the device, so the **Console** evaluates JavaScript in the real app, **Sources** sets breakpoints and steps through code, **Network** lists `fetch`, `XMLHttpRequest` and `<Image>` requests, and **Components** shows the React tree with editable props and state. It only works in debug builds on Hermes; native code still goes to Xcode or Android Studio.

code

bash · 7 lines
bash
# Start the dev server (bare React Native CLI or Expo)
npx react-native start
# or
npx expo start

# With the app running in a debug build, press j in this terminal
# to open React Native DevTools for the connected app.

go deeper

for a junior

Recall the two ways in: j in the dev server terminal and Open DevTools in the Dev Menu. Name the Console, Sources, Network and Components panels and what each is for.

for a middle

Explain that DevTools is the Chrome DevTools frontend talking CDP through the dev server to Hermes on the device, why it needs a running dev server and a debug build, and what changed in 0.83.

for a senior

Show you know its limits in practice: no release builds, no native frames, reconnection after native rebuilds, several targets at once, and when to reach for Xcode or Android Studio instead.

for a principal

Frame it as a tooling standard: one CDP-based debugger the whole team shares, which keeps onboarding simple and removes the drift that browser-hosted and plugin-based debuggers used to cause.

## What React Native DevTools is **React Native DevTools** is React Native's built-in JavaScript debugger. It became stable and the **default debugger in React Native 0.76**, and in React Native 0.87 it is the recommended way to debug an app's JavaScript, since the older built-in debuggers have been removed. Its user interface is the **Chrome DevTools frontend**, so anyone who has debugged a web page recognises the panels, but it does not run your code in a browser. It attaches to the **Hermes** JavaScript engine running inside the app on the device, emulator or simulator. The connection uses the **Chrome DevTools Protocol (CDP)**. The dev server (Metro, started by `npx react-native start` or `npx expo start`) includes `@react-native/dev-middleware`, which runs an **inspector proxy**: each running app registers with it, and the DevTools window talks to that app's Hermes runtime through it. That is why the dev server must be running for DevTools to work. Three boundaries are worth stating in an interview: - **Scope**: it debugs React and JavaScript concerns (logs, breakpoints, network requests, the component tree). It is not a native debugger; Kotlin, Swift or Objective-C++ code in a native module is debugged in Android Studio or Xcode. - **Engine**: it needs Hermes, the default engine (Hermes V1 since 0.84). An app on the community JavaScriptCore package is debugged differently. - **Build type**: DevTools, the Dev Menu and LogBox are all disabled in release builds. ## Opening it 1. Start the dev server and run a debug build of the app. 2. Press `j` in the dev server's terminal. Metro asks the inspector proxy for its debug targets: with none it warns that no targets are connected, with one it opens that target, and with several it prints a numbered list (the first nine) so you pick the app to debug. 3. Alternatively, open the in-app **Dev Menu** and choose **Open DevTools**. On iOS the item is disabled, with a prompt to connect to Metro, while the app cannot reach the dev server. On first launch DevTools opens on a welcome pane with the console drawer open, and the tabs across the top lead to the other panels. Since **0.83** the frontend opens in a **bundled desktop app** instead of a browser tab. The dev server downloads and caches that shell in the background. The app needs no Chrome or Edge install, reuses and raises its window when a breakpoint hits or the same app reconnects, and is isolated from browser extensions that used to break it. If the binary cannot be downloaded or started, for example behind a corporate firewall, DevTools falls back to opening in Chrome or Edge. ## The panels you debug with | Panel | What you do there | Worth knowing | |---|---|---| | **Console** | Read and filter logs, evaluate JavaScript in the running app, use Live Expressions and Preserve Logs | Metro's terminal stopped streaming `console.log` in 0.77; this is where logs live | | **Sources** | Open files (`Cmd/Ctrl+P`), set breakpoints, step through code, read scope, call stack and watch expressions | A `debugger;` statement reaches the device through Fast Refresh; the app shows a *Paused in Debugger* overlay | | **Network** | Inspect `fetch()`, `XMLHttpRequest` and `<Image>` requests: timings, headers, response previews, the Initiator stack | New in 0.83; Expo apps also show Expo's own *Expo Network* panel | | **Components** | Browse the rendered React tree, select an element on the device, view and edit props and state | Components optimised by React Compiler carry a *Memo* badge | In the Components panel, hovering a node highlights the matching element on the device, and the **Select element** button lets you tap something in the app to jump to its component. The same window also holds the Performance, Memory and React Profiler panels; those are profiling tools and are a topic of their own. ## When the connection drops DevTools shows a **"Debugging connection was closed"** dialog when: - the app is closed or crashes on the native side; - a new native build is installed; - the dev server is stopped; - a physical device is unplugged. You can **dismiss** it to keep reading the last state, or choose **Reconnect DevTools** once the cause is fixed. Breakpoints survive reloads and reconnection, which the older debuggers never managed reliably. ## Mistakes interviewers listen for - Looking for app logs in the Metro terminal instead of the Console panel. - Opening `localhost:8081/debugger-ui` in Chrome: that was Remote JS Debugging, removed in 0.79. - Expecting DevTools inside a release build. - Expecting it to step into a native module's platform code.

  • What happens when you press j with an Android emulator and an iOS simulator both running the app?
    Metro asks its inspector proxy for the current debug targets. With exactly one it opens DevTools straight away; with several it prints a numbered list, showing at most the first nine, and you press the number of the app you want. Pressing `j` again lets you open a second DevTools window for the other target.
  • Why might DevTools open in a Chrome tab rather than the desktop app on a locked-down work laptop?
    Since 0.83 the dev server downloads and caches the desktop shell in the background. If that binary can't be downloaded or started, typically because of a corporate firewall, DevTools falls back to launching the same frontend in Chrome or Edge until the next dev server start. The panels work the same; you only lose the desktop app's window handling.
  • In a bare React Native CLI project, why don't console.log calls print in the npx react-native start terminal any more?
    Log forwarding through Metro was deprecated in 0.76 and removed in 0.77 so that debugging goes exclusively over the Chrome DevTools Protocol. Logs now belong in the DevTools Console panel, which can filter by level, inspect objects and keep messages across reloads with Preserve Logs.

The dev server is a switchboard operator: each running app phones in and registers, and pressing j asks the operator to patch your DevTools window through to one of them. Hang up the switchboard by stopping Metro and every call drops.

saying these in an interview costs you the question

  • Open Chrome at localhost:8081/debugger-ui to debug the app's JavaScript.
  • React Native DevTools runs your JavaScript inside the desktop window.
  • DevTools can be opened from the Dev Menu of a release build.
  • You can step through a native module's Kotlin or Swift code in it.
  • App logs are read in the Metro terminal.
open as a page

What replaced Remote JS Debugging and Flipper in React Native, and why was the old Chrome remote debugger unreliable?

level: middleimportance: must knowfreq 56%

basics

~20 s

React Native DevTools, the default since 0.76. Remote JS Debugging ran the app's JavaScript in desktop Chrome instead of on the device, so behaviour differed and New Architecture modules broke; it was removed in 0.79. Flipper's integration left new projects in 0.74.

open as a page

In React Native DevTools, which requests does the Network panel capture, and what are its current gaps?

level: middleimportance: should knowfreq 30%

basics

~20 s

Since 0.83 the Network panel records fetch(), XMLHttpRequest and <Image> requests while DevTools is connected, with headers, timings, previews and an Initiator stack. It does not yet show WebSocket events, mock responses or throttle, and misses custom stacks such as Expo Fetch.

open as a page

In a React Native school-portal app, tapping Sign in shows a generic error and nothing crashes. How would you step through the failed login with React Native DevTools?

level: seniorimportance: should knowfreq 40%

basics

~20 s

Reproduce with DevTools open, read the login request's status and body in the Network panel, jump to the sending code via Initiator, then pause on caught exceptions or a breakpoint and inspect scope, call stack and the form's state in Components.

open as a page