Benchmarks

To show what that React Native Boost buys you, the example app in the repository serves as a benchmark by rendering a heavy, constantly-updating screen and measuring the frame rate. We compare three configurations on the exact same device: the baseline (stock React Native), a core-optimized configuration that turns on React Native's own overhead-reduction feature flag (detailed below), and React Native Boost.

Higher frames per second (FPS) means a smoother UI. The ideal target is 60 FPS, which means you need to commit one new frame every ~16 ms. Once the app can't keep up, FPS drops and the interface starts to stutter.

Results

iOS: The baseline starts dropping frames early and falls to ~32 FPS under the heaviest load, while React Native Boost holds a solid 60 FPS far longer and stays roughly 69% faster at the top end. The core-optimized build (the middle line) recovers part of the gap — around 8–15% under heavy load — but Boost stays roughly 50% ahead of even that.

Android: Same shape, with Boost about 55% faster at the heaviest load (and higher at intermediate heavy loads). The core-optimized build helps here too — roughly 10–22% at heavy loads. This device is noisy enough that a handful of loads couldn't be measured reliably for the core comparison and are left out of that middle line (you'll see small gaps), but Boost's lead is unambiguous throughout.

Methodology

The test screen is a live crypto-style order book: two stacked columns of rows, each row a few pieces of Text, all updating many times per second from a simulated price feed.

Each run is a clean comparison on identical inputs:

1. One build, three configurations. From a single release build we run the baseline (stock React Native), a core-optimized configuration with React Native's reduceDefaultPropsInText flag enabled, and React Native Boost. Nothing else changes.
2. Sweep the load. Each configuration steps through a range of row counts, from light to heavy.
3. Hold the temperature constant. Phones throttle as they heat up, which would corrupt the comparison. So before every capture the app idles until the device cools back to a fixed thermal floor, and every sample records the device's thermal state. All three series are measured at the same temperature.
4. Measure FPS, repeatedly. The app runs a continuous animation loop and records how long every frame takes over a fixed window, reporting the average FPS (plus 95th-percentile frame time and the share of dropped frames). Each point is captured several times and reported as the median, with the replicate spread drawn as error bars on the graphs.
5. Validate the core comparison. Boost's frame rate doesn't depend on the reduceDefaultPropsInText flag, so the Boost curve should land identically in the baseline and core-optimized runs. This is used as a built-in sanity check / validator. At any load where the two disagree (or the device is simply too noisy to trust), the point is dropped as unreliable.

Everything runs as a release/production build on the New Architecture.

Secondary benchmarks

Number of React tree nodes

We're also making a second, device-independent measurement. For a single row, we count the React tree nodes (fibers). One of the ways React Native Boost impacts an app's performance is by deleting a layer of these fibers per element it optimizes.

Fewer nodes means less for React to build and re-check on every frame.

Time-to-mount

For previous versions of React Native, we also published benchmarks showing heavy performance improvements in initial render (mounting) times. Text components optimized through React Native Boost rendered up to 50% faster on iOS, and around 20% faster on Android, compared to the baseline standard Text component.

Thanks to various improvements to the reconciler and other internals in React Native 0.78, this advantage has shrunken to only around ~4-6% in recent benchmarks. React Native Boost remains advantageous for frequently-updated screens, less so for screens with only a lot of static components.

reduceDefaultPropsInText feature flag in React Native

In React Native 0.82, a reduceDefaultPropsInText feature flag was introduced. It trimmed the Text wrapper's output so that unset accessibility/aria-* props no longer crossed the JS→native boundary on every render. It shipped disabled by default and has since graduated: in newer React Native the flag is gone and the optimized behavior is simply the default. It's one step in React Native's long-term goal of reducing the Text and View wrapper overhead directly in core. The Deep Dive traces its full lifecycle.

// Additional note: Our long term plan is to reduce the overhead of the <Text>
// and <View> wrappers so that we no longer have any reason to export these APIs.

In our benchmark, the core-optimized series in the graphs enables reduceDefaultPropsInText (on the React Native version measured here, where the flag still exists). Under heavy render load it recovers roughly 8–15% of the baseline's lost frame rate on iOS (a bit more on Android), but closes only part of the gap. NativeText, the component React Native Boost uses under the hood, stays well ahead — around a 50% margin over the core-optimized build at the heaviest loads on iOS. As React Native lands more of these optimizations, we expect the core-optimized line to keep rising toward React Native Boost.