Build Gesture-Driven Mobile Animations That Run at Sixty FPS

There is a specific kind of cheapness a user feels the moment they touch a mobile app. The card they are dragging lags a frame or two behind their thumb. The swipe-to-delete stutters when a list is loading in the background. The pull-to-refresh hitches right as the network call fires. Nothing is broken, but the app feels heavy, and that feeling is almost always the same root cause: the animation is running on the JavaScript thread, and the JavaScript thread is busy.

Solving this is not about writing cleverer animation code. It is about running the animation somewhere the busy work cannot reach it. React Native gives you exactly that capability through Reanimated and Gesture Handler, which move gesture and animation logic onto the UI thread so it runs at a steady 60 frames per second no matter what the JavaScript thread is doing. Here is how that works and how to build interactions that stay smooth under load.

Why animations stutter in the first place

React Native traditionally runs your JavaScript, including most animation logic, on a single JS thread. That thread is also where your component renders, your state updates, your data processing, and your network response handling happen. When any of that work is in progress, the animation has to wait its turn, and the frames it should have drawn during that wait get dropped. A dropped frame is a visible stutter.

This is why an animation that looks perfect in isolation falls apart in a real app. In the demo, the JS thread has nothing else to do, so the animation gets every frame. In production, the user starts a drag at the exact moment a list is fetching and parsing data, the JS thread is saturated, and the drag lags because the code that updates its position cannot run on time. It is the mobile cousin of the web problem in breaking up long tasks so your main thread stays responsive: one busy thread and an interaction stuck behind it. The animation is competing with everything else for the same thread, and it loses.

The fix is to stop competing. If the animation runs on a different thread, one dedicated to the UI, then the JS thread being busy no longer matters, because the animation is not waiting on it.

Worklets: code that runs on the UI thread

Reanimated's core idea is the worklet, a small JavaScript function that executes on the UI thread instead of the JS thread. You mark a function as a worklet, and Reanimated runs it on the native UI thread where rendering happens, so it can update animation values in time for every frame regardless of what the JS thread is doing.

A worklet is declared by putting the 'worklet' directive as the first line of the function, though in practice the hooks and gesture handlers you use generate worklets for you. The point is the threading: animation logic that lives in a worklet runs frame-perfect because it is on the thread that draws the frames, not the thread that is busy with your business logic.

The data these worklets animate lives in shared values. A shared value, created with useSharedValue, is a mutable container that lives on the UI thread and can be read and written from worklets. You drive an animation by updating a shared value, and because both the value and the worklet that reads it are on the UI thread, the whole loop runs without ever crossing over to the JS thread or waiting on it.

Wiring a gesture to a shared value

The combination that produces buttery gesture-driven interactions is Gesture Handler feeding Reanimated. Gesture Handler recognizes the touch, its handlers run as worklets on the UI thread, and they directly update the shared values that drive the animation. The user's finger and the thing on screen move together because the entire path, from touch to position update to render, stays on the UI thread.

A drag looks like this in shape:

const translateX = useSharedValue(0);
const translateY = useSharedValue(0);

const pan = Gesture.Pan()
  .onUpdate((e) => {
    'worklet';
    translateX.value = e.translationX; // updates on the UI thread
    translateY.value = e.translationY;
  });

const style = useAnimatedStyle(() => ({
  transform: [
    { translateX: translateX.value },
    { translateY: translateY.value },
  ],
}));

The onUpdate handler runs as a worklet, so it sets translateX and translateY directly on the UI thread without ever touching the JS thread. The useAnimatedStyle worklet reads those values and produces the transform, also on the UI thread. The element tracks the finger exactly, frame for frame, even if the JS thread is in the middle of parsing a large API response. That is the difference: the drag does not care what the rest of the app is doing, because none of the rest of the app is on its thread.

This pattern generalizes to the whole vocabulary of mobile gestures. Swipe-to-delete is a horizontal pan that animates a row off screen past a threshold. Drag-to-reorder is a pan that updates a list item's position and reshuffles around it. Pinch-to-zoom is a pinch gesture driving a scale shared value. Each one stays smooth because the gesture handler and the animation both live on the UI thread. None of it matters, of course, if your touch targets sit in the wrong place, which is why thumb zones and target sizing decide whether the gesture ever gets a chance to feel good.

Beyond gestures: scroll effects and transitions

The same engine powers the scroll-driven and layout effects that make an app feel polished. A parallax header, where the hero image moves at a different rate than the content scrolling over it, is a scroll position shared value driving a transform on the UI thread, so the parallax stays locked to the scroll even during heavy rendering. Sticky elements that transform as they pin, enter and exit animations as items mount and unmount, and shared element transitions where an element appears to fly from one screen to the next, all of these run as worklets and stay at frame rate because they are not on the JS thread.

Shared element transitions deserve a specific mention because they are where cheap and premium diverge most visibly. When a user taps a thumbnail and it expands smoothly into the full-screen image on the next screen, that continuity makes the app feel considered. When the same transition janks, it feels broken. It is the same gap between a prototype and a product that the micro-interactions that separate a premium product from a prototype is built around. Running it on the UI thread is what keeps it smooth through the screen change, which is exactly the moment the JS thread is busy mounting the new screen, the kind of transition window an app shell so users never stare at a spinner is designed to cover.

Keeping it fast as the app grows

The reason this architecture matters more over time is that the JS thread only gets busier as an app gains features. Early on, even a poorly-threaded animation might look fine because there is little else competing. As the app accumulates data fetching, state management, and rendering work, animations that share the JS thread degrade, while animations on the UI thread stay exactly as smooth as they were on day one. Building gesture and animation logic on Reanimated from the start is how you keep the app feeling fast at scale rather than watching it slowly stutter as it grows.

A couple of practices keep it honest. Keep the work inside worklets to the minimum needed to update the animation; a worklet doing heavy computation can stall the UI thread the same way heavy JS work stalls the JS thread, just on the other side. And when a gesture needs to trigger real application logic, like committing a delete to your backend after a swipe completes, hand that work back to the JS thread explicitly at the end of the gesture, so the animation runs on the UI thread and the side effect runs where it belongs. The animation stays smooth; the business logic stays correct. The same care extends to motion that should never run at all for some users, which is where animating boldly while respecting users who get sick from motion comes in.

This is the level of interaction quality we build into the mobile apps we ship, because on a phone the feel of the gestures is a large part of whether an app reads as premium or as cheap. When the budget question is whether a native build is even worth it, deciding when a PWA beats a native app is the call that comes first, since this kind of UI-thread smoothness is one of the things a native runtime buys you. A drag that tracks the thumb perfectly and a transition that flows between screens are not decoration; they are what makes an app feel like it was built with care, and they hold up specifically because they do not depend on a thread that is doing everything else.

The smooth app

The end result is an app where the gestures feel connected to the user's hand and stay that way under real conditions. The drag tracks the finger frame for frame while a list loads in the background. The swipe-to-delete glides even mid-fetch. The shared element transition flows smoothly through the screen change. None of it stutters when the app gets busy, because the animations were never on the busy thread to begin with.

That is the whole trick: not faster animation code, but animation code that runs where the slowness cannot reach it. Move the gestures and the motion onto the UI thread with Reanimated and Gesture Handler, and the cheap, laggy feeling that betrays a rushed mobile app simply does not happen, no matter how much the rest of the app is doing.