Hero Animations in React Native: Shared Elements in 2026

What is a hero animation, mechanically?

An element that appears to travel between two screens: the thumbnail in a grid becomes the header of the detail screen, moving and resizing through the navigation instead of being replaced by it. Mechanically, nothing travels. Two different components live on two different screens, and the system animates a bridge between their measured frames, which is why every implementation reduces to the same three steps: measure the source, measure the destination, animate something between them while the real screens swap underneath.

Understanding that makes the ecosystem’s options legible, because they differ only in who does the measuring and who owns the bridge.

Which implementation should you actually use in 2026?

Route	How it works	Where it stands
Reanimated shared element transitions	Tag views with sharedTransitionTag; the library bridges	The designated future; still flagged experimental
react-native-shared-element	Native measurement + bridge, navigation wrappers	The old standard, aging visibly (4,827 weekly downloads)
Manual overlay (“magic move”)	You measure, clone, and animate in a portal	Full control; the production fallback that always works

The honest read: Reanimated (5,266,534 weekly downloads, the ecosystem’s animation backbone) carries the official-future energy, and its shared-element API has worn the experimental label for a long time, with real cases, resize-mode morphs, interrupted gestures, nested navigators, where it still surprises. The dedicated shared-element library solved the hard native problems years ago but trails the new-architecture world. The manual overlay is unglamorous and fully yours, and serious apps ship it more often than the marketing suggests.

For a new build: try the Reanimated tags first since the API cost is two props, and keep the overlay technique in your pocket for the transition that misbehaves, because one always does.

How does the manual overlay actually work?

Four moves, all standard tools:

1. Measure the source with measureInWindow at tap time: frame, border radius, the image’s URI.
2. Mount a clone in an overlay portal (a sibling above the navigator) at exactly the source frame, and hide the real source.
3. Navigate immediately underneath while animating the clone to the destination frame, position, size, radius, on a spring.
4. Hand off: when the destination mounts and reports its frame, the clone fades out over the real element.

The craft hides in two details. Image resize-mode morphing: a grid thumbnail renders cover while the detail header may be contain or a different aspect, and naive frame interpolation makes the image visibly stretch mid-flight; the fix is animating the clone’s container while the image inside keeps cover semantics, cropping honestly throughout. And interruption: the user can tap back mid-transition, so the bridge must be reversible from its current position rather than restartable, which is exactly what springs driven by gesture-aware shared values give you and timeline-based animations do not.

Everything runs on the UI thread through Reanimated worklets; a bridge that stutters is worse than no hero at all, and the diagnosis discipline when it does stutter is the usual one from the Reanimated error triage: verify what is actually running on which thread instead of trusting the claim.

Where do hero animations belong, and where not?

They earn their cost where the element genuinely persists in the user’s mind: grid-to-detail images (the canonical case), avatars opening into profiles, the mini-player expanding into the full player. They subtract where the connection is conceptual rather than visual, a list row “becoming” a form, and the animation invents continuity the content does not have, reading as motion for its own sake.

Respect the platform’s grammar too: durations around 300 to 400 milliseconds with spring settle, Reduce Motion swapping the travel for a crossfade, and the gesture-driven back swipe scrubbing the transition rather than replaying it. The same continuity logic at smaller scale, one surface morphing rather than two screens bridging, is the bottom-sheet family covered in the Reanimated sheet build.

Hero transitions are also where screen design and motion design meet: the source and destination layouts must agree about the element (same aspect family, compatible radii) or no bridge looks right. Free VP0 designs keep that agreement built in across grid-detail pairs, which an agent generates from with the tags or overlay wired to frames that were designed to correspond. The same UI-thread Reanimated discipline drives a swipe-to-buy button animation.

What to choose

Start with Reanimated’s sharedTransitionTag for the canonical image cases and accept its experimental edges; drop to the manual overlay for the transition that fights back or needs gesture scrubbing; reach for the legacy shared-element library only when maintaining code that already uses it. And skip the hero entirely where the element does not truly persist, because the strongest motion system is the one that knows when to stand still.

Frequently asked questions

How do I build hero animations in React Native? Tag the source and destination views with Reanimated’s sharedTransitionTag for the standard cases, and use the manual overlay technique, measure the source, animate a clone in a portal above the navigator, hand off to the destination, when you need full control or gesture scrubbing. Free VP0 designs supply grid-detail screen pairs whose layouts already correspond.

Is react-native-shared-element still maintained? It exists and works for the architecture it was built for, but its momentum has faded (a few thousand weekly downloads against Reanimated’s millions) and the ecosystem’s direction is Reanimated’s built-in shared element transitions. New projects should not start on it.

Why does my image stretch during the transition? Frame interpolation is fighting resize modes: a cover thumbnail morphing toward a different aspect stretches if you animate the image itself. Animate the clone’s container and let the image keep cover semantics, cropping honestly through the flight.

How long should a shared element transition take? Around 300 to 400 milliseconds with a spring settle, scrubbable by the back gesture rather than replayed, and replaced by a crossfade when Reduce Motion is on. Anything past half a second turns delight into delay.

When should I not use a hero animation? When the element does not visually persist between screens: a row becoming a form, a button becoming a page. Bridging conceptually-different content invents continuity that is not there, and a clean push communicates the change more honestly.