Why is a React Native development build a poor place to judge jank, and what should you measure on instead?

## What changes between a debug and a release build A React Native **development build** is built for fast iteration and good error messages, not for speed. When Metro serves the bundle in development mode (the bundle request carries `dev=true`), several things are different from what users run: | Aspect | Development build | Release build | |---|---|---| | `__DEV__` global | `true` | `false` | | React renderer | development build with extra checks and warnings | production build | | Bundle | served by Metro, unminified | embedded in the app, minified | | Dev tooling | Fast Refresh, LogBox, debugger connection | absent | | Error messages | detailed, with component stacks | minimal | Every one of those extras costs time on the **JS thread**. Components validate more, warnings are formatted, development-only code paths run, and the tooling listens for changes. The React Native performance guide states that JavaScript thread performance suffers greatly in dev mode and that this is unavoidable, and tells you to always test performance in release builds. ## Why that matters for jank Jank means missing the frame budget - about **16.7 ms** at 60 Hz and **8.3 ms** at 120 Hz. Development overhead can easily push a render that takes a few milliseconds in release over the deadline in debug. The result: - You may **chase jank that does not exist** for users and spend days optimising code that was fine. - You may **misjudge which thread** is at fault, because dev mode inflates JS-thread cost far more than UI-thread cost. - Your before-and-after numbers are **not comparable** with what ships, since the overhead is not constant across code paths. The reverse mistake is also real: a simulator on a fast laptop hides problems that a budget Android phone reveals. Release mode and realistic hardware belong together. ## How to get a release-like measurement 1. **Build a release variant.** In a project using the React Native CLI scripts, `yarn android --mode release` and `yarn ios --mode Release` build and install release builds. In an Expo project, `npx expo run:android --variant release` and `npx expo run:ios --configuration Release` do the same. 2. **Run it on a real device**, preferably one close to your slowest supported users. 3. **Reproduce the interaction** several times; the first run after install can include one-off work. 4. **Only then measure and profile**, using a profiler that attaches to a release-like build, since the in-app Dev Menu tools are not available in a pure release build. Note that a pure release build has no Dev Menu, so the in-app **Perf Monitor** overlay is a development tool. Use it to separate JS-thread from UI-thread jank during development, and confirm the finding on a release build with a profiler or with careful manual testing. ## Reading dev-mode signals sensibly Development builds are still useful for performance work, as long as you treat what they show correctly: - A **UI-thread** stutter in debug (scrolling or native transitions stuttering while JS is idle) is more likely to be real, because dev overhead mostly lands on the JS thread. - A **JS-thread** stutter in debug is a lead to verify, not a result. - **Relative** comparisons between two approaches measured in the same dev build can hint at direction, but confirm the winner in release. - Development-only warnings in the console are worth fixing for correctness, but their cost is not what users pay. ## Why the overhead lands on the JS thread Most of what development mode adds is JavaScript: the development renderer's extra validation, the formatting of warnings with component stacks, the LogBox machinery that collects them, and the Fast Refresh runtime that tracks modules so they can be swapped. All of that runs on the same **JS thread** as your components and handlers, and competes for the same frame budget. The native side of a debug build also carries some extra checks, but the gap users would never see is overwhelmingly a JS-thread gap. That is why a JS-thread drop in debug deserves more suspicion than a UI-thread drop. ## Common mistakes - Filing a performance bug from a simulator running a debug build. - Assuming the release build is "the same code, just minified" - the renderer and runtime checks differ too. - Leaving the debugger attached while judging smoothness. - Measuring once on a flagship phone and declaring the screen fast. The rule interviewers want to hear is short: development mode is slow on purpose, so performance claims are made on release builds on real devices.