Version 7 is stable while main contains version 8 alpha
React Navigation v7.3.18 is the latest stable native package release, while the repository README says the default branch contains the upcoming version 8. The measured commit makes that distinction tangible: @react-navigation/native identifies itself as 8.0.0-alpha.44. A developer cloning main to patch a production app is therefore working ahead of the stable line. Stable consumers should install released 7.x packages or work from the 7.x branch instead of assuming main matches npm's default release.
The repository is a collection of related packages rather than one small library. Our measured checkout contained 918 files, about 149,145 source lines, and pnpm workspaces for packages plus an example app. It covers core routing, native and JavaScript stacks, bottom and top tabs, drawers, UI elements, devtools, and lower-level routers. That shared home makes coordinated releases possible, but it also explains why contributing carries much more code than adding one navigator to an application.
Native screens require platform setup after the core package
The v7 getting-started guide requires React Native 0.72 or newer and names Expo 52 as the minimum for Expo Go. Most navigators also need react-native-screens and react-native-safe-area-context. iOS developers run the CocoaPods linking step. Android projects must set the screens fragment factory in MainActivity so view state survives activity restarts, and the guide currently tells Android apps to disable predictive back because React Navigation does not support it yet.
Those steps are manageable, though they are easy to miss when someone sees only npm install @react-navigation/native. The full contributor install pulled 1,247 packages and occupied 758 MB in our sandbox. That is the monorepo development footprint, not a claim about the size added to a consumer app. A real app's dependency set varies by navigator: native stack is lighter conceptually, while drawer and JavaScript stack paths bring gesture and animation libraries that need their own native setup.
What happened when we ran it
Our Node 22 sandbox installed the React Navigation monorepo at commit b0352b5 in 28 seconds. pnpm added 1,247 packages and used 758 MB on disk. The build completed in 35 seconds. We ran inside an unprivileged Debian container with 3 CPUs, 8 GB of RAM, and no secrets. The checkout itself occupied 49 MB before the dependency installation, so most of the measured disk cost came from the development dependency tree.
Jest finished in 27 seconds with 1,303 passed and 0 failed out of 1,303. The repository had 12 CI workflow files and workspaces, but our scan found no Dockerfile and no dedicated tests directory. The clean suite is strong evidence for the JavaScript and TypeScript paths exercised by those commands. It does not replace device checks for gestures, activity restoration, deep links, accessibility, or transitions across the iOS, Android, and web targets an app supports.
Static configuration cuts v7 type and link boilerplate
React Navigation v7 provides static and dynamic configuration. The static API uses an object-shaped route tree, can infer more TypeScript information, and can generate deep-link paths automatically. Dynamic configuration keeps screen lists and options inside components, which helps when the route tree itself changes at runtime. The TypeScript guide warns that nested dynamic navigators need explicit parameter lists, and manual useNavigation annotations cannot be guaranteed to match the navigator actually above the component.
This is where React Navigation earns its place in a complex app. Route names, nested parameters, linking, headers, and transition options live in one model instead of separate mobile and web routers. Our 35-second build and 1,303 passing tests make that model credible at the measured commit. Application tests still need to cover the routes that matter. Open issue 13231, for example, reports reused nested-parameter object references being ignored on a later navigation, with a fresh outer object as the reported workaround.
Web support omits gestures and keeps server rendering limited
The v7 web guide supports browser history and URLs through React Native for Web, but it asks developers to use links or buttons that render anchors instead of relying on imperative navigation. Native-stack animations and gestures are unavailable on web. JavaScript stack transitions are disabled by default there, and its gestures are also unavailable. Drawer gestures do not carry over either. A shared route model survives, while interaction details and responsive layout still need web-specific decisions.
Server rendering is another boundary. The guide calls support limited and says React Navigation works best with fully client-rendered apps; hosting also needs every application route to serve the SPA entry file. The measured project spans 49 MB and 918 source files because it covers several platforms and navigators, but that scope does not turn it into a web framework. Teams whose primary product depends on server-first routing, loader conventions, or identical gestures across platforms should choose a router centered on those requirements.
A 2026-09-12 push and 847 open items show an active large project
GitHub recorded 24,500 stars and a last push on 2026-09-12. Search results separated the 847 open items into 799 issues and 48 pull requests. The stable native 7.3.18 release arrived on 2026-08-26, alongside continuing version 8 alpha work. New reports were still being filed and discussed in September, including strict peer-dependency behavior for an alternate renderer and nested-navigation parameter reuse. The queue is large, but current source, releases, and issue discussion rule out a simple abandonment reading.
Our 28-second install, 35-second build, and 27-second test run all succeeded, which supports using the stable line while the 8.x work develops. React Navigation is the sensible default when a React Native team wants configurable navigation across native and web. Expo Router reduces route declarations for Expo apps by using files, while Wix's React Native Navigation gives native controllers more authority. Pick based on application architecture, then pin the chosen major version and test the real back, link, restore, and transition flows.

