react-native-pager-view is a healthy, actively maintained package that is safe to depend on today — it is the community-standard swipeable pager component, wraps the native Android ViewPager2 and iOS UIPageViewController, and pulls over a million weekly downloads with a regular release cadence. The interesting security question is not "is this one package malicious" (it is not) but how you reason about a native-code React Native dependency in general, because react-native-pager-view is a textbook example of the category: small JavaScript surface, real native modules underneath, and a maintenance record you should actually check rather than assume.
If you searched for react native pager view expecting a quick "yes/no," the honest answer is yes — with the same caveats you should apply to any dependency that ships compiled native code into your mobile app.
What react-native-pager-view is
The package, published as react-native-pager-view on npm and maintained by Callstack, provides a horizontally (or vertically) swipeable pager — the swipe-between-screens interaction you see in onboarding flows and tabbed views. It replaced the older, deprecated @react-native-community/viewpager, and it is the component Expo bundles for pager functionality, which is a large part of why its adoption is so wide.
Crucially, it is not pure JavaScript. It binds to platform-native view controllers, which means installing it adds native code to your build. That native surface is the part worth thinking about, because a JavaScript-only bug is sandboxed by the JS engine, while native code runs with the app's full privileges.
Reading the maintenance signals
The most useful security signal for an open-source dependency is not its current vulnerability count — it is whether someone will fix the next problem quickly. On that measure react-native-pager-view scores well. Its maintenance status reads as healthy: it ships new versions regularly (at least one release within recent quarters), the Callstack-maintained GitHub repository sees active issue and pull-request engagement, and it carries several thousand stars alongside its million-plus weekly downloads.
Those numbers matter for a specific reason. A popular, actively maintained package means a discovered vulnerability gets a patched release fast, and a large user base means problems get noticed fast. The opposite profile — a native-code package with one maintainer and no release in two years — is the genuine risk case, because you would be shipping unmaintained native code into your app with no one to fix it when something breaks. react-native-pager-view is not that; but the habit of checking is what protects you from the packages that are.
The native-code supply-chain risk
Here is where a component like this deserves more scrutiny than a pure-JS utility. When you add react-native-pager-view (or any native module), the compiled native code becomes part of your application binary. Two consequences follow.
First, npm audit and JavaScript-focused scanners see the npm metadata but do not analyze the native Android and iOS source. Your dependency scanning has to understand that the package version maps to native code, and track advisories against the package as a whole. Second, the package's own dependencies — and its build-time tooling — are part of your supply chain too. A native module typically has a thin dependency tree, which is good, but you should still generate a software bill of materials for your mobile app so you know exactly which version of this and every other native module you shipped in a given release. An SCA tool such as Safeguard can produce that inventory and flag a version with a known advisory before it reaches a store submission.
Pinning and upgrading safely
react-native-pager-view has a version detail that bites teams: version 7.x and later support only React Native's New Architecture, while older lines like 6.9.1 remain in use on projects that have not migrated. Picking the wrong major for your architecture produces build failures or subtle runtime breakage, and — more to the security point — tempts teams into pinning to an old version and never moving again.
Pin deliberately:
{
"dependencies": {
"react-native-pager-view": "8.0.0"
}
}
Pin to an exact version (or a tight range), commit your lockfile, and treat upgrades as reviewed changes rather than automatic bumps — native modules can shift build requirements between majors. But do keep moving. The failure mode is not upgrading too often; it is freezing on an old version for years because a major bump once caused friction, which is exactly how an unpatched dependency ages into a liability. Match your major to your architecture (New vs. old), then track releases within it.
The same reasoning applies to sibling native packages you will likely have alongside it. If your app also uses something like react-native-view-shot for capturing views to images, apply the identical discipline: check maintenance health, pin the version, and scan the native surface — every native module is its own small supply chain.
Vetting any React Native native dependency
The checklist that react-native-pager-view happens to pass is the one to run on every native dependency before you adopt it:
- Maintenance health — recent releases, active issues/PRs, more than a single maintainer.
- Adoption — download volume and stars as proxies for how fast problems surface and get fixed.
- Dependency footprint — a shallow tree with few transitive dependencies is less to worry about.
- Architecture compatibility — does the version line match your New/old architecture choice?
- Advisory history — how has the maintainer handled past security reports?
Run that once at adoption and let automated scanning watch it continuously afterward. The npm security best practices guide covers the broader install-time risks that apply to the JavaScript half of any React Native dependency tree.
FAQ
Is react-native-pager-view actively maintained?
Yes. It is maintained by Callstack, ships releases regularly, sees active engagement on its GitHub repository, and has well over a million weekly downloads. Its maintenance status reads as healthy, which is the key signal that a future vulnerability would get patched promptly.
Does react-native-pager-view have known vulnerabilities?
There is no widely publicized critical CVE defining this package's reputation, but "no known issues today" is a moving target for any dependency. The right posture is to pin the version, generate an SBOM for your app, and let dependency scanning alert you if a future advisory is published against the version you shipped.
Which version of react-native-pager-view should I use?
Match the major to your React Native architecture: version 7.x and later require the New Architecture, while 6.x lines remain for projects still on the old architecture. Pin to an exact version, commit your lockfile, and upgrade within your compatible major as new releases land.
Why do native React Native packages need extra security attention?
Because they ship compiled native code that runs with your app's full privileges and is not analyzed by JavaScript-only scanners like npm audit. That makes maintenance health and version tracking more important than for pure-JS utilities — you are trusting native code you did not write and cannot easily inspect.