It all starts with navigation

Magiera frames navigation as an early, consequential choice for React Native developers: switching libraries later can mean rewriting much of an app. He reviews the field’s evolution and says the range of solutions reflects how difficult navigation is, with more changes likely ahead.

NavigatorIOS wrapped iOS’s UINavigationController, but offered limited customization and did not suit Android’s different navigation patterns. The cross-platform Navigator used route configuration and push, pop, and reset commands, but its JavaScript-driven animations could stutter while screens rendered or loaded data. NavigatorExperimental used Animated’s native driver to move transitions off the JavaScript thread, though its name made adoption harder.

Wix’s React Native Navigation created native view controllers for screens, while placing the navigation bar outside the app made some customizations and gestures difficult. Magiera describes React Native Gesture Handler as a way to recognize gestures on the UI thread and connect their results to native-driven animations. React Navigation offers extension points for custom behavior and can use native transitions and back-swipe gestures.

Magiera compares view hierarchies and explains that screens kept in memory can retain images, location tracking, camera sessions, and rendering loops even when they are offscreen. Those views may miss native window lifecycle events that would let them release resources. Native Screens provides screen containers with an active state, keeping only the screens needed for a tab or stack transition active.

Magiera says Native Screens can be integrated with React Navigation by replacing some views with native screen components, without changing app code. He also says it would be included in Expo SDK 30. In his comparison, an Android app pushing many image-heavy screens slows down without Screens, while the version using Screens transitions faster because image views can release resources.