A react-native-pager-view npm install pulls native Android and iOS code into your app, not just JavaScript, which is exactly why React Native packages deserve stricter vetting than typical web dependencies. Every React Native library that touches a native module ships Kotlin, Java, Objective-C, or Swift that compiles into your binary and runs with your app's full permissions. This post uses four widely used packages as case studies for a vetting process you can repeat on anything: react-native-pager-view, react-native-paper, react-native-video, and react-native-config.
Why mobile dependencies raise the stakes
On the web, a malicious or vulnerable package executes in a browser sandbox and can be rolled back with a deploy. In a mobile app, dependency code ships inside a signed binary distributed through app stores. Remediation means a new release, review queue time, and waiting for users to update. Native module code also sidesteps JavaScript-level protections entirely; it can open sockets, read files within the app sandbox, and link against system frameworks.
So the vetting question is not just "is this package popular?" but "who controls the native code I am about to compile into my product, and how fast could I remove it?"
Case study 1: react-native-pager-view
react-native-pager-view provides swipeable page containers backed by Android's ViewPager2 and a native iOS implementation. It is the community replacement for the deprecated ViewPager component that once lived in React Native core.
What vetting looks like here:
- Provenance: it lives under the react-native-community umbrella on GitHub, with maintenance driven by well-known React Native consultancies. Packages under an organization survive individual maintainer burnout better than personal-account repos.
- Native surface: it renders UI and handles gestures; it should not need network or storage permissions. If a UI-only package's Android source requests permissions in its manifest, that is a red flag worth reading line by line.
- Release cadence: frequent releases tracking new React Native versions is healthy. It also means you will be upgrading often, so pin exact versions and review changelogs.
Case study 2: react-native-paper npm package
The react native paper npm package (react-native-paper, maintained by Callstack) is a Material Design component library. It is almost entirely JavaScript, which changes the risk profile: less native attack surface, but a large dependency on correct handling of user-supplied strings in components.
For the react-native-paper npm install, focus your review on:
- Transitive tree size. Component libraries pull in icon sets, color utilities, and animation helpers. Run
npm ls --alland know what arrived. - Update discipline. UI kits are the classic place where teams freeze on an old major "because upgrading is painful," then accumulate unpatched transitive advisories for years. Budget for the majors.
Case study 3: react-native-video
The react-native-video npm package wraps ExoPlayer on Android and AVPlayer on iOS. Media players are historically fertile ground for parser vulnerabilities, and this package inherits the patch state of the players it wraps.
Vetting questions specific to media libraries:
- Which ExoPlayer or AndroidX Media3 version does your installed release bind to, and does that version have open advisories upstream?
- Do you play remote media from URLs influenced by users or third parties? If so, treat the player as an attack surface and keep it current.
- Does DRM or offline caching write to disk, and is that cache path excluded from backups if content is sensitive?
This is a case where a scanner that only reads package.json misses the point. The risky code is the native player dependency declared in the library's Gradle and CocoaPods files, so your composition analysis needs to reach the native lockfiles (Podfile.lock, Gradle dependency reports) too. An SCA platform such as Safeguard that ingests both JavaScript and native manifests gives you the full picture rather than the top half.
Case study 4: react native config npm package and the secrets trap
The react native config npm package (react-native-config) injects values from .env files into native build configs and JavaScript. It is genuinely useful for switching API endpoints between staging and production. It is also the single most misused package in mobile security reviews, because developers put secrets in it.
Read this twice: values shipped via react-native-config are compiled into your app and are recoverable by anyone who downloads your APK or IPA and runs strings on it. The library's own documentation says it is not a secure storage mechanism. API keys with billing attached, signing secrets, and admin tokens do not belong in any client-side env file. Use it for non-sensitive configuration only, and move secrets behind your backend. We cover the discovery side of this in detecting malicious postinstall scripts, but leaked-by-design config is the more common finding.
A repeatable vetting checklist
Before any React Native package reaches your main branch:
- Check maintenance signals. Last publish date, open issue triage, and whether the repo is a personal account or an organization. Unmaintained native modules are a compounding liability because they block React Native upgrades. See abandoned open source project risks for how these decay.
- Read the install hooks.
npm view <package> scriptsshows postinstall behavior. Native modules legitimately run build steps; anything fetching remote scripts deserves rejection. - Diff the native code on upgrades. JavaScript diffs get reviewed; Gradle and podspec changes often do not. Make them part of the PR.
- Pin exact versions and commit lockfiles. Both
package-lock.jsonandPodfile.lock. - Scan continuously. New advisories land against old versions. A weekly scan of the full tree, native manifests included, turns "we shipped that vulnerable player for eight months" into a one-sprint fix.
FAQ
Is react-native-pager-view safe to use?
It is a maintained, community-governed UI package with a narrow native surface (view rendering and gestures). The main operational risk is version drift against React Native releases, so pin exact versions and track its changelog rather than worrying about its intent.
Should I store API keys in react-native-config?
No. Anything injected through react-native-config ends up in the shipped binary and can be extracted from the APK or IPA. Use it for non-sensitive values like endpoint URLs and feature flags, and keep real secrets server-side.
How do I audit the native dependencies of a React Native package?
Look past package.json to the library's android/build.gradle and .podspec files, and to your project's Podfile.lock and Gradle dependency reports. That is where wrapped players, networking stacks, and SDKs are declared, and where advisories actually apply.
Do popular packages still need vetting?
Yes. Popularity filters out low-effort malware but says nothing about unpatched transitive dependencies, permission creep, or maintainer account takeover. The checklist above takes minutes per package and catches all three.