In a React Native app, how much time does one frame get at 60 Hz and at 120 Hz, and what does dropping a frame mean?

## Where the numbers come from A screen refreshes at a fixed rate, and each refresh shows one still image - a **frame**. Motion is an illusion built from a steady stream of frames, so smoothness depends on producing every frame before the display asks for it. The time available for one frame is the **frame budget**: | Refresh rate | Arithmetic | Budget per frame | |---|---|---| | 60 Hz | 1000 ms / 60 | about **16.7 ms** | | 90 Hz | 1000 ms / 90 | about **11.1 ms** | | 120 Hz | 1000 ms / 120 | about **8.3 ms** | The React Native docs frame performance around this number: iOS and Android devices display at least 60 frames per second, which leaves at most 16.67 ms to do all the work for a frame. On a 120 Hz panel the same arithmetic leaves about half that. ## What "dropping a frame" means If the work for a frame is not finished when the display refreshes, nothing new is ready, so the screen shows the **previous frame again**. That is a **dropped frame**. One drop is rarely visible; several in a row read as a stutter, a frozen animation, or a tap that seems ignored. The docs give a concrete scale: a state update on a root component that makes React re-render expensive subtrees for **200 ms** costs about **12 frames** at 60 Hz - and every JavaScript-driven animation freezes for that time. Key points to hold on to: - The budget is a **deadline per frame**, not an average. A screen that averages 10 ms per frame but has one 80 ms spike still stutters. - A higher refresh rate **shrinks** the budget. Moving from 60 Hz to 120 Hz halves it, so work that fit comfortably can start missing deadlines. - Dropped frames are not errors and nothing crashes; the app simply looks and feels unresponsive. - Work that finishes quickly but runs **every frame** (a JS handler on each scroll event, for example) competes for the same budget. ## Two threads, two budgets In React Native the frame deadline applies to more than one thread, which is what makes jank here different from a single-threaded web page: 1. **The JS thread** runs your React components, effects, event handlers and any JavaScript-driven animation. If it is busy past the deadline, React cannot respond to touches or commit updates that frame. 2. **The UI (main) thread** owns the native views. It draws them, runs native scrolling and runs native transitions such as those of `@react-navigation/native-stack`. Each thread can miss frames independently. A frozen JS thread does not stop an already-rendered `ScrollView` from scrolling, because the scroll lives on the main thread; the scroll events are delivered to JS, but receiving them is not required for the scroll to happen. Conversely, a main thread struggling to draw an expensive view hierarchy stutters even when JavaScript is idle. Telling the two apart is the first diagnostic step, and the in-app **Perf Monitor** reports frame rates for this purpose. ## Why the budget shapes everyday decisions The number turns into rules of thumb: - Keep synchronous JS work in a single task well under the budget; split long jobs into small chunks so input and rendering can interleave. - Treat a **120 Hz** device as the stricter test case, not the easier one. - Keep animations and gestures that must stay smooth off the JS thread where the animation library allows it, so a busy JS thread cannot freeze them. - Judge frame rates on a **release build**: development mode adds extra runtime work on the JS thread and makes the budget look far tighter than it is for users. ## Common mistakes - Treating 60 fps as an average to hit over a second rather than a deadline every frame. - Assuming a 120 Hz phone gives the app more room; it gives less time per frame. - Blaming "React Native is slow" before checking which thread missed the deadline. - Measuring jank in a debug build and optimising code that is fine in release. The frame budget is the unit every later performance conversation is measured in: re-render cost, list windowing, animation drivers and startup work all come down to whether a thread finished its share of work before the next refresh.