react-native-screen-transitions puts the whole transition in a component tree

Install is two steps and the second one is large

The package itself installs like any npm dependency:

npm install react-native-screen-transitions

The peer dependencies are the interesting part, and there are seven of them:

npm install react-native-reanimated react-native-gesture-handler \
  @react-navigation/native @react-navigation/native-stack \
  @react-navigation/elements react-native-screens \
  react-native-safe-area-context

That list tells you the architecture. This is not a standalone navigation library that replaces React Navigation; it is a transition layer that runs on top of `@react-navigation/native-stack`, Reanimated and Gesture Handler. The README lists all seven as peer dependencies. Its compatibility section specifically describes the supported Reanimated and Gesture Handler versions for v3.

Transitions as slots and presets, not as config

The feature list describes a component model rather than a settings object. There is full animation control for screen enter, exit and gesture-driven states, and the mechanism underneath is a set of transition slots: one for content, one for backdrop, one for surface, and additional slots for custom tagged elements. The backdrop and surface being separate slots is the structural detail, since it lets an animation treat the dimmed background and the moving panel as independently animated things rather than one composite view.

On top of that sit built-in presets for common modal, card and shared-transition patterns, so the common cases do not require you to assemble slots by hand.

The Bounds API covers the two hardest cases. Shared element and fullscreen navigation zoom transitions are expressed through it, which is the feature people usually hand-roll and usually get subtly wrong because it needs a shared coordinate space between two screens. Snap-point sheets come with gesture-aware coordination for `ScrollView` and `FlatList`, meaning a scroll gesture and a sheet drag gesture resolve rather than fight.

There is also integration for blank stack, native stack and Expo Router, which matters more than it sounds: the library works whether you use React Navigation directly or route through Expo Router's file-based layer.

The compatibility table is the constraint to read first

The support section is short and specific. v3, described as current, supports Reanimated v3, Reanimated v4, and React Native Gesture Handler v2, and the table repeats that pairing.

That table matters because the release history shows how fast this moves. Recent tags include v4.0.0 and v3.13.0 both on 2026-08-27, less than a minute apart, with v3.12.0 on 2026-08-09. So v4 exists as a tag while the README still describes v3 as the current supported line. A project arriving at a v4.0.0 install and a README documenting v3 is a real scenario, not an edge case, and it means checking which major you actually resolved before trusting any example.

The last push was on 2026-09-21, and the repository has no CHANGELOG to fall back on. The `CHANGELOG.md` is not in the top-level entries either, so release notes live on the tags themselves.

On the tooling side, the project is developed as a bun workspace. `package.json` declares workspaces covering `packages/*` and `apps/*`, `bun.lock` and `bunfig.toml` are the lock and config, `biome.json` handles linting through a `lint` script that runs `biome check packages/react-native-screen-transitions/src`, and `lefthook.yml` sets up git hooks. `knip.json` with a `knip` script suggests a check for unused exports, which is a sign the maintainer treats API surface as something to prune. Releases go through release-it with separate stable, alpha, beta and rc configs, so prerelease channels exist as a real option rather than a convention.

What it costs and what it does not replace

Three limits are worth stating plainly.

First, this is animation, not navigation architecture. You still choose your navigator, you still own route structure, and a misconfigured native stack will fail in ways this library cannot mask. The blank stack and native stack integrations are conveniences, not replacements.

Second, Reanimated and Gesture Handler are peer dependencies, so their compatibility requirements should be checked separately.

Third, the documentation lives on an external site rather than in the repository. The README points at screen-transitions.esjr.org and says only to see the documentation site. Given how much of the API is component composition, that site is the actual reference, and there is no in-repo API listing to grep.

The comparison is with React Navigation's own animation configuration and with writing the transition yourself with Reanimated and a shared value. If you need one custom modal transition, doing it directly is shorter and has no new dependency. The case for this library is several screens with distinct transition behaviour, where hand-rolling means maintaining a small animation library of your own. The comparison for sheet behaviour specifically is a gesture-handler sheet implementation, which is a well-understood but fiddly piece of code involving scroll and pan gesture arbitration.

The README asks for sponsorship on GitHub or through a coffee link and names Ed as the author. That is normal for a library of this size and quality, and it is also a real consideration when you are putting navigation transitions in a shipping app.

Editorial conclusion

Adopt react-native-screen-transitions when your navigation needs custom enter, exit and drag-to-dismiss behaviour that the native stack animator will not give you, since the transition is a component you compose rather than a config object you fill in. Do not adopt it without reading the compatibility table, or if you want zero animation dependencies, because the peer list contains seven packages. Verify first that the current major line matches your installed Reanimated version, since the support table ties v3 to Reanimated v3 and v4 and Gesture Handler v2.

Frequently asked questions

Official sources

1. eds2002/react-native-screen-transitions on GitHub
2. License: MIT
3. Project website
4. README
5. Releases