Originally published on expo.dev/blog by Janic Duplessis.

This is a guest post from [*Janic Duplessis](https://www.linkedin.com/in/janic-duplessis-4aa83171/) - He is the head of consulting at App&Flow and a long-time React Native contributor. *
…

Picture a login screen with a slowly drifting background, the kind of subtle motion that makes a product feel polished rather than built. Simple enough. We implemented it with Reanimated and shipped it. But every now and then, you could catch a frame drop. Just enough to feel slightly off, the kind of thing that bugs you once you’ve seen it.

The root cause is that Reanimated runs on the UI thread every frame. When the app does significant work during that frame (a re-render kicks in, a list scrolls, an input updates), the animation budget shrinks, and that slow background translate becomes a slow background stutter.

At App & Flow, we build React Native apps and tools for product teams that care about getting the details right. Fluid, native-feeling UIs are a big part of that. So instead of working around the problem, we went looking for a better approach.

Core Animation on iOS hands animations off to the OS render server and never touches your thread again. Once you give it a CAAnimation, the system drives it and your app is out of the loop entirely. We wanted that in React Native. That’s how react-native-ease came about, a declarative animation library that drives everything through platform APIs (Core Animation on iOS, ObjectAnimator on Android) with no JS loop, no worklets, and no shadow tree commits per frame.

But building it raised a question we wanted to answer honestly: how much does the choice of animation library actually matter?

So we measured it. Across four approaches, two platforms, and both high-end and mid-range devices, we tracked per-frame UI thread overhead. This post shares what we found, and tries to answer the questions that actually matter: how large is the frame penalty? In what kinds of apps does it matter? And what should you prioritize when choosing an animation library?

💡 The frame drops on the Reanimated side are simulated. We injected artificial UI thread pressure to reproduce what happens in a busy app. Real-world jank depends on your workload, device, and how much else is happening on the UI thread at the same time.

The four React Native animation libraries tested

All benchmarks were run in April 2026 with Expo SDK 55, React Native 0.83, Reanimated 4.3.0, and react-native-ease 0.7.0.

We compared four animation approaches:

• Ease: react-native-ease, using platform APIs directly. Animations are described as props on the JS side and driven natively with no per-frame JS involvement.
• Reanimated (Shared Values): the standard worklet-based approach. Values are driven on the UI thread via a C++ worklet runtime, but each frame still updates props through the shadow tree.
• Reanimated (CSS Animations): Reanimated’s newer CSS animation API. Declarative like Ease, but still backed by Reanimated’s animation engine.
• RN Animated: React Native’s built-in Animated API with useNativeDriver: true. Values are driven natively, but the implementation varies by platform.

We also tested Reanimated with its static feature flags enabled, specifically ANDROID_SYNCHRONOUSLY_UPDATE_UI_PROPS and IOS_SYNCHRONOUSLY_UPDATE_UI_PROPS, which let Reanimated skip the shadow tree commit when only non-layout props (like transform and opacity) are updated. A meaningful optimization worth calling out separately.

Note: RN 0.85 introduced a new Shared Animation Backend that will eventually make the feature flags unnecessary. Reanimated’s integration is in progress but not yet released.

How the benchmark measures per-frame overhead

We built a benchmark screen into the example app that animates N views simultaneously in a loop (translateX, 2s, linear, repeating). We used a custom Expo native module to measure per-frame overhead:

• iOS: We swizzle CADisplayLink’s factory method to intercept all display link callbacks registered by any framework, then measure wall-clock time per callback aggregated by frame timestamp.
• Android: We use Window.OnFrameMetricsAvailableListener, which reports ANIMATION_DURATION, LAYOUT_MEASURE_DURATION, and DRAW_DURATION from the platform’s frame metrics system.

We ran 5-second collection windows per test and multiple configurations to show both worst-case and best-case Reanimated performance.

Benchmark results: per-frame UI thread cost on iOS and Android

Android (Moto G8 Plus)

Android is the most apples-to-apples comparison between libraries. Every approach runs on the UI thread, so what you’re seeing is a direct measure of how much work each animation engine adds per frame. No tricks, no shortcuts.

How much does build configuration matter? (50 views, avg ms)

The single biggest variable for Reanimated performance isn’t which animation API you pick. It’s whether you’re testing in a debug or release build.

The red line is the 16.67ms frame budget at 60fps. In debug mode, Reanimated SV and CSS both blow past it at just 50 views, actively dropping frames. The same animation in a release build comes in at 11ms. Debug builds lie. If you notice animation jank during development, reproduce it in a release build before panicking.

The feature flags add another 11–19% on top by bypassing the shadow tree commit for non-layout props. They can cause visual bugs in some apps so they’re opt-in, but worth testing if you’re seeing overhead.

How does overhead scale with view count? (Release, all FF, avg ms)

💡 500 views is a stress test, not a realistic target. If you're animating 500 things at once, the animation library might not be your biggest problem.

At 10–100 views, all approaches stay under the frame budget on average, though Reanimated and RN Animated are within 5ms of it at 100 views, leaving little headroom for the rest of your frame work. At 500 views, only Ease stays under budget. Reanimated SV hits 36ms, more than twice the frame budget; and this is the optimized configuration.

iOS (iPhone 15 Pro)

iOS is where the architectural difference becomes impossible to ignore. On Android, all libraries share the UI thread, so the comparison is fair. On iOS, Ease gets to cheat (in the best way). Core Animation runs in a separate OS render server process, completely outside your app. Once Ease registers a CAAnimation, the system takes over and your thread is free to do other work. That’s why Ease shows ~0.01ms across the board: there is genuinely nothing happening on the UI thread per frame. The tradeoff is that Core Animation animations can’t be read or interrupted from JS mid-flight, which is exactly why gesture-driven animations still belong to Reanimated.

Display link callback time per frame, ms (release build)

The absolute numbers are lower than Android because the measurement captures only UI thread callback time. But the point stands: on iOS, Ease adds no UI thread cost regardless of how many views are animating, while every other approach keeps doing work every frame.

Why React Native animation libraries differ in per-frame cost

The shadow tree tax

Every frame, Reanimated’s worklet computes new values and commits a prop update through the shadow tree. That commit runs Yoga layout, prop diffing, and view mutations. When you’re animating transform or opacity (properties with zero effect on layout) every bit of that work is wasted. You’re paying the full price of a layout pass to nudge a blob three pixels to the left. Yoga doesn’t need to know.

The feature flags (ANDROID/IOS_SYNCHRONOUSLY_UPDATE_UI_PROPS) short-circuit this by pushing visual prop updates directly to the UI layer, skipping the layout pass entirely. On the Moto G8 Plus at 50 views they cut Reanimated SV from 11.87ms to 10.57ms (-11%) and CSS from 11.20ms to 9.06ms (-19%). They’re opt-in because they can cause visual bugs in some apps, but if you’re chasing overhead they’re the first thing to try.

RN Animated

RN Animated with useNativeDriver: true skips the JS thread per frame too, but drives animations through a separate native animation module that carries bookkeeping overhead per animated node. It holds up fine at low-to-mid view counts, but scales worse than Reanimated CSS as the number of animated views climbs. This is partly because it lacks the shadow tree optimizations the feature flags enable.

When your animation library choice matters in production apps

It matters most for long-running or slow animations: skeleton loaders, drifting backgrounds, ambient UI effects. A single dropped frame in a 5-second animation is noticeable, and other work (data fetching, re-renders, user interaction) is almost always happening at the same time. It also matters for anything in a list, where you can easily have hundreds of animated items on screen at once. On low-end devices, small per-frame overhead compounds fast, and your users notice before you do.

For short one-shot transitions (a button press, a toast, a modal) the overhead is negligible and any library works fine.

Worth noting: Ease only covers this specific use case. Gesture-driven animations (scroll-linked, drag, swipe) and anything that changes layout properties (width, height, padding) still need Reanimated or RN Animated. Ease is purpose-built for declarative, trigger-based animations on visual properties.

React Native 0.85 and the Shared Animation Backend

React Native 0.85 ships an experimental Shared Animation Backend, a unified animation engine built directly into the renderer by Meta and Software Mansion. Once Reanimated’s integration ships, SYNCHRONOUSLY_UPDATE_UI_PROPS becomes unnecessary because shadow tree bypass will be the default path, and the gap between “default Reanimated” and “optimized Reanimated” effectively goes away.

The architectural difference remains, though. Ease has no per-frame animation engine at all. Even with a faster backend, Reanimated still computes values and pushes prop updates every frame. That overhead doesn’t disappear; it just gets smaller. We’ll update the benchmarks once the integration ships.

Running the React Native animation benchmark yourself

The benchmark is built into the example app. Clone the repo, run yarn example ios or yarn example android, and tap Benchmark from the demo screen. Source is in example/src/demos/BenchmarkDemo.tsx and the native module is in example/modules/frame-metrics/.

One note: use release builds. Debug mode inflates Reanimated’s numbers significantly. So if your numbers look alarming, that’s likely why.

yarn example ios --configuration Release
yarn example android --variant release

*react-native-ease is built by App & Flow, a Montreal-based React Native engineering studio recommended by Expo.*