In a real app
The Performance panel is the one teams underuse. Combined with React Native’s Web Performance APIs (stable since 0.83: performance.mark, performance.measure), it lets you instrument a startup or a navigation with marks placed in code and read them on the same timeline as React renders. That is how I turn “the app feels slow” into numbers before touching any code. The Network panel has documented limits: WebSocket only on the Canary channel since 0.88, no mocking or throttling, and on Expo the separate “Expo Network” panel is still there next to it.
The classic tooling pitfall is a React Native version below 0.76 or an engine other than Hermes: React Native DevTools is unavailable, and tutorials point to Flipper, whose integration was removed from the template. Another frequent case: a “Debugging connection was closed” dialog after a rebuild or a crash; “Reconnect DevTools” is enough once the cause is fixed, without restarting Metro if it is still running.
For the React tree, the “select element” button locates a component on the device and the “Highlight updates” setting shows re-renders live, which settles most debates about unnecessary useMemo calls within minutes.
Related terms
Hermes
Meta’s JavaScript engine for React Native, the default since 0.70, which precompiles the bundle to bytecode at build time.
Metro
React Native’s JavaScript bundler: it resolves, transforms, and serializes your code into a bundle, and runs the dev server.
Fast Refresh
React Native’s hot reloading: a component edit is applied within a second or two while local state is preserved.
Cold start (startup time)
Launching the app from scratch, process included: native init, bundle load, first React render, up to a usable screen (TTI).
Development build
A debug build of your own app that includes expo-dev-client: your native modules, plus a launcher to connect to Metro.