The hidden cost of skipping a React Native upgrade

You skip a React Native upgrade. Maybe one version. Maybe two. The app works. Customers don't notice. The team uses the freed capacity to ship features. The decision pays off.

For about a year.

This post is what happens after that year. The costs that don't show up on a roadmap but show up on every engineering meeting from then on.

Upgrade debt compounds

A one-version upgrade — say, 0.74 to 0.75 — is small. The upgrade helper renders a clean diff, you apply it, dependencies mostly slot in, you test, you ship. A team that does this every quarter spends a few engineer-weeks a year on upgrades and stays current indefinitely.

The same team that skips for two years isn't behind by two upgrades. It's behind by the cumulative drift of everything that pinned to React Native versions in between. Reanimated bumped, React Navigation bumped, the New Architecture flipped to default, Gradle bumped, Cocoapods bumped, the JS bundler changed defaults.

The shape of the cost curve isn't linear. The first version is cheap. The second is roughly the same. By the fourth or fifth, the work is no longer "upgrade React Native" — it's "upgrade React Native, the build tooling, half the dependencies, the native modules, and the privacy manifests, simultaneously."

CVE exposure

React Native itself has a small CVE history. The framework's surface area for security issues is narrow. What's broad is the dependency graph it pins.

Each React Native release ships with a specific set of dependency versions in its template. When you stay on an old React Native release, you stay aligned with old versions of:

• Underlying iOS Cocoapods (some of which have shipped CVE fixes)
• Underlying Android Gradle plugins and Maven dependencies
• JavaScript packages whose newer versions patched issues you're not getting
• The bundler, which has had its own security history

You can manually upgrade individual dependencies inside an old React Native version — overrides, resolutions, force-pinning. But every override is one more thing to maintain, and at some point the override graph itself becomes a maintenance project.

Recent receipts: the 2024 Axios CVE chain hit teams whose old React Native version was still pulling an unpatched Axios through a transitive dependency. The 2025 @react-native-aria typosquat reached apps whose dependency graphs hadn't been audited recently. Each one was preventable with current dependencies.

Store-submission risk

Apple and Google don't reject apps for running old React Native versions. They reject apps for failing current submission requirements.

What's changed in the last 18 months:

• Apple privacy manifests. Enforced for SDKs in 2024. Old React Native versions don't ship a manifest. You can backport one, but it's fragile.
• Apple required-reason APIs. Enforced. Old library versions don't declare reasons. You replace them or fork them.
• Google Play target SDK. Google enforces a target SDK floor each year. Old React Native build configurations target old SDKs by default. Upgrading the target SDK in isolation often breaks the old build.
• Android 14+ behavior changes. Foreground services, photo picker, partial media access — old React Native versions don't handle these defaults gracefully.

The pattern: a team submits a routine update. It gets rejected. They scramble to figure out which requirement they missed. The fix turns out to require upgrading React Native, which they thought they had another year to defer.

The dependency graph drifts away from you

Library authors publish for current React Native versions. Their peer dependency ranges encode "what we tested against." When they update, the range moves forward and drops the older version.

You stay on 0.70. A year later, half your libraries have published new versions that no longer support 0.70. You're stuck on old versions. Those old versions in turn pin old dependencies. You stop being able to install new libraries cleanly because the ecosystem assumes a more current base.

The result: every new dependency becomes a project. Every new feature that requires a new library involves negotiating with peer ranges, ERESOLVE errors, and forks.

Recruiting and retention friction

The market for React Native engineers is asymmetric. The supply is large; the supply that wants to work on years-out-of-date React Native is small.

You'll see this in two places:

1. Hiring. Candidates ask about the stack. They hear "React Native 0.69." They politely move on. The candidates you do attract are often less senior or specifically open to upgrade work — which is fine for one role, awkward for a team.
2. Retention. Engineers join, do their job for a year, and then start asking when the upgrade is happening. When the answer is "we keep deferring it," some of them update their resumes.

This is harder to put on a spreadsheet than CVE risk or store rejections, but every engineering manager who's lived through it knows what it costs.

The emergency upgrade pattern

The cost of skipping isn't paid evenly. It's paid in one event, called "the upgrade we couldn't postpone anymore."

Common triggers:

• An App Store rejection that requires a current React Native version to fix
• A high-severity CVE that affects a library version your old React Native pins
• A required new dependency that won't install against your current setup
• A senior engineer leaving and the team realizing only they understood the patches

The upgrade gets attempted under deadline. It stalls. Features stop shipping. Engineering morale takes the hit. The actual engineering cost is higher than it would have been; the opportunity cost is much higher.

The actual math

Numbers from teams we've worked with. Variance is real, but the shape is consistent.

The decision people often think they're making — "should we upgrade now, or save the effort?" — isn't the right framing. The right framing is "do we pay now, in scheduled chunks, or pay later under emergency conditions and at multiples?"

Frequently Asked Questions