Caveats & Trade-offs

Native Stack with withScreenTransitions

withScreenTransitions is a compatibility layer for @react-navigation/native-stack.

For screens that enable transitions, the adapter switches native stack to containedTransparentModal, disables the native animation, and lets Screen Transitions render the animation over that container.

That works, but it comes with real trade-offs:

• visually, a background screen may look tappable while still being blocked by the transparent modal layer
• dismissal can feel worse than blank stack because native removal and JS state synchronization are coordinated separately
• platform-specific edge cases are more likely here than on blank stack

Use withScreenTransitions when an existing native-stack flow needs a custom transition. Use Blank Stack when the transition system should own the full presentation model.

Blank Stack Trade-offs

Blank stack gives you the most features and the most control.

It is the default recommendation for:

• custom interpolators
• gestures
• snap sheets
• overlays
• bounds transitions
• navigation zoom
• embedded flows

The trade-off is that blank stack is still a JavaScript navigator. When people compare performance, the fair comparison is a JS stack, not a fully native presentation stack.

In practice, blank stack is where the library works best. Just keep the runtime model in mind when you design ambitious transitions.

Internal release-build testing has shown that simple settled transitions, such as an opaque page push/pop loop or a settled modal sheet loop, can be competitive with the baseline React Navigation JS stack on tested devices.

That does not mean every benchmark will show blank stack as faster. More callback-sensitive push/pop measurements can differ because transition completion is coordinated differently, even when the visual motion feels just as smooth or smoother in practice.

Choose blank stack because you want the richer transition model, gesture control, and motion flexibility. Do not choose it because you expect every timing benchmark to come out lower.

Deep Linking

Deep linking is supported.

These navigators still sit on top of React Navigation, so normal deep-linking flows are very much possible. The caveat is that the more complex the transition choreography becomes, the more opportunities there are for a deep link to land in a visually bad or unexpected transition state.

If you hit a deep-link-specific bug with a complex animation flow, open an issue on GitHub with a reproduction.

First Screen Does Not Animate by Default

By default, the first screen in a stack does not animate from its closed state on initial mount. It starts already settled.

That is intentional. Most apps do not want the initial route animating in on first render.

If you do want that behavior, there is an experimental escape hatch:

1<Stack.Screen
2  name="Home"
3  component={HomeScreen}
4  options={{
5    experimental_animateOnInitialMount: true,
6  }}
7/>

experimental_animateOnInitialMount is experimental and may change.