react-native-screens is a low-level library that exposes native navigation primitives to React Native, and its security profile is mostly about supply-chain hygiene rather than an API you call directly. Most developers never npm install react-native-screens on purpose — it arrives as a dependency of React Navigation's native stack navigator. That indirect relationship is exactly why it belongs in a security guide: it is native code (Objective-C, Swift, Kotlin, Java) running inside your app that many teams have never consciously reviewed. This post explains what the package does, why native dependencies deserve extra scrutiny, and how to keep react native screens from being a blind spot.
What react-native-screens actually does
React Navigation, the standard navigation library for React Native, needs a way to represent screens. By default it could use plain View components, but that leaves performance and platform behavior on the table. react-native-screens, maintained by Software Mansion, provides native screen containers instead — UIViewController on iOS and fragment-backed containers on Android — so the operating system can properly manage the view hierarchy, memory, and transitions.
The library's own documentation is explicit that it is not meant to be used directly: it is a dependency of full navigation libraries. When you install React Navigation's native stack (@react-navigation/native-stack), react-native-screens comes along as a required peer. The current release line is 4.x. The main knob most apps ever touch is enabling it, which recent versions do automatically:
import { enableScreens } from 'react-native-screens';
enableScreens(); // on by default in current versions
Why a native dependency needs extra scrutiny
Here is the security-relevant point: react-native-screens is not pure JavaScript. It ships compiled native modules that link into your iOS and Android binaries and run with the full permissions of your app. A JavaScript-only dependency is constrained by the JS runtime; a native module is not. That raises the stakes for supply-chain integrity in two ways.
First, a compromised release of a native package can execute platform code, not just JavaScript, giving an attacker a far more capable foothold. Second, native code is harder to audit — you cannot skim it as easily as a JS file in node_modules, and most teams never look at the Objective-C or Kotlin their dependencies bring in. The combination means native React Native dependencies like this one should be pinned, monitored, and updated deliberately, exactly because they are easy to forget.
Managing react-native-screens in your supply chain
The practical controls are the same ones that apply to any critical dependency, applied with discipline because this one is native and transitive:
- Pin the exact version and commit the lockfile. Use
npm cior the yarn equivalent so a republished version cannot silently change your native build. Confirm what you resolved:
npm ls react-native-screens
- Keep it aligned with React Native and React Navigation.
react-native-screenstracks React Native's architecture closely, including the New Architecture (Fabric). A mismatched version is both a stability and a maintenance problem, and running an old version to avoid a migration means missing whatever fixes shipped since. - Monitor advisories. Subscribe to Dependabot or an SCA tool for the package so any future advisory reaches you as an alert. Because it is transitive, it will not appear in your
package.json, which is exactly how transitive dependencies slip past manual review. - Verify the maintainer and download source. Install only from the official package under the Software Mansion organization, and be alert to typosquats of popular RN packages.
An SCA tool is useful here specifically because react-native-screens is transitive: it can trace that the package entered your tree through @react-navigation/native-stack, tell you which version resolved, and flag it if a known issue is ever published against it.
The bigger picture: React Native dependency risk
The reason to care about one navigation dependency is that a React Native app is a large tree of them, and a meaningful share are native modules — camera access, secure storage, push notifications, biometrics. Each is compiled code with device permissions, and each is a supply-chain surface. The mobile-specific risks that matter most are hardcoded secrets shipped in the bundle, over-broad permissions requested by dependencies, and insecure data storage — none of which a generic web scanner is built to catch. Treat your native dependency tree as part of your attack surface, generate a bill of materials for the mobile build, and review new native dependencies with the same care you would give server code. Our academy covers mobile supply-chain security in more depth.
Do you need to configure it for security?
For most apps, no direct configuration of react-native-screens is needed — it does its job beneath React Navigation and exposes almost no security-relevant surface of its own. The security work is upstream and around it: keep the version current and aligned, know it is in your tree, and fold it into whatever dependency-monitoring you run for the rest of the app. The failure mode is not misconfiguring react-native-screens; it is forgetting it exists until an advisory lands and you discover a native dependency you never audited has been in every build for two years.
FAQ
What is react-native-screens used for?
It exposes native navigation container primitives to React Native so React Navigation can render screens as native view controllers and fragments instead of plain View components, improving performance and platform behavior. It is a dependency, not a library you use directly.
Is react-native-screens safe?
It is a legitimate, actively maintained library from Software Mansion. Its security risk is supply-chain rather than API-level: it ships native code, so pin the version, keep it aligned with your React Native version, and monitor it for advisories.
Do I need to install react-native-screens myself?
Usually not directly. It comes in as a peer dependency of React Navigation's native stack navigator. You should still pin and monitor it, since transitive native dependencies are easy to overlook.
Why do native React Native dependencies need extra care?
Because they ship compiled code that runs with your app's full permissions, unlike JavaScript-only packages constrained by the JS runtime. A compromised native dependency can execute platform code, and native modules are harder to audit, so pinning and monitoring them matters more.