How Often Should You Update a React Native App?

If a React Native app still opens and the team can still ship, upgrading the framework is easy to postpone. I know because I have worked on an app where we turned the React Native upgrade into an annual event. Every time it came around, it was stressful.

The framework was only one part of it. We also had to update supporting packages, find replacements for libraries that were no longer maintained, carry patches, and fix behavior that changed underneath the app. On one upgrade, the modal package we depended on stopped working the way we needed, so the team had to replace it while the release clock was already moving.

That experience is why my normal recommendation is simple: review and upgrade a live React Native app twice a year.

I usually like the beginning of January and the end of June or beginning of July. Those are planning checkpoints, not dates handed down by React Native or Expo. They give the team two deliberate chances to decide what needs to move before a store rule, operating-system change, or unsupported dependency makes the decision for them.

Why twice a year is a reasonable baseline

React Native moves faster than many business owners realize. The project currently plans a new minor release about every two months and supports the latest three minor series. Its stable channel still uses 0.x.y version numbers, but that does not mean the releases are treated as experimental. The React Native versioning policy says stable versions are tested and that breaking changes, features, and critical fixes are communicated through minor and patch releases. The release overview explains the six-release annual cadence and support window.

I would not tell an owner to chase all six releases. That can create plenty of motion without improving the product. I would tell them to make the upgrade decision visible at least twice.

Six months is short enough that the team is less likely to jump across a long stack of framework, build-tool, native-platform, and library changes in one project. It is also long enough to plan the work, test the app's real workflows, and avoid turning maintenance into a permanent feature freeze.

The goal is not to be on the newest version for bragging rights. The goal is to keep the distance between the app you own and the ecosystem it depends on within a range your team can understand.

The two windows serve different purposes

The January review happens after the major fall operating-system releases have had time to reach real users. By then, the team should have better evidence about what actually changed, which regressions matter to the app, and whether a dependency or build tool needs attention.

The late-June or early-July review is preparation. Apple opened its current major iOS beta cycle in June, which is visible in the Apple developer release history. That gives mobile teams a window to test important workflows before the fall release reaches customers. The point is not to ship beta tooling into production. It is to stop guessing about whether the next platform release will affect the app.

This timing also creates a useful business rhythm. One checkpoint looks backward at what the fall release exposed. The other looks forward at what the next release may require.

Waiting combines work that did not need to be combined

When teams say an upgrade was painful, the React Native version is rarely the whole story. The project may also contain:

• packages whose maintainers have moved on;
• patches that only apply to one dependency version;
• an older Xcode, Android Gradle Plugin, Kotlin, or Node toolchain;
• native project changes that were skipped during earlier upgrades;
• app-store requirements that now demand a newer SDK or target API; and
• a release pipeline nobody wants to touch because only one person understands it.

Each item can be manageable by itself. Waiting lets them arrive in the same project.

That is not theoretical. Starting August 31, 2026, Google Play requires most new apps and updates to target Android 16, API level 36. It also limits availability for older existing apps that do not meet its newer target-level rule. Google documents the dates and exceptions in its target API requirement. Apple made a similar submission move earlier this year by requiring iOS and iPadOS uploads to use the iOS 26 SDK or later, according to its SDK minimum requirements.

Those policies are good examples of why “the app still works” is not a maintenance plan. A binary on a phone and a product your team can continue building, testing, and submitting are not the same thing.

Expo makes this easier, but it does not remove ownership

My own opinion of Expo has changed a lot. I came from the era when a bare React Native project felt like the only way to keep enough native control. Today, I recommend that many teams begin with Expo because it removes a lot of early build and configuration friction.

That does not mean every team should leave Expo as soon as the app gets traction. That part depends on the product, the team, cost, compliance needs, build volume, and how much control the organization actually needs. Expo's current tooling can support production work, and EAS Build can manage cloud builds and signing credentials or let the team bring its own.

It also does not mean upgrades disappear. Expo releases several SDKs each year, and each SDK targets a particular React Native version. Expo's SDK reference connects those versions to their React Native, Android, iOS, Xcode, and Node requirements. Its own upgrade guide recommends moving one SDK at a time, aligning dependencies, running Expo Doctor, and reading the release notes for version-specific changes.

That is the part I want an owner to notice. A managed tool can reduce the work. It cannot decide when the business should accept the risk of change, how the app will be tested, or who owns the release when something breaks. That is also why embedded product engineering leadership has to cover the release path and decision ownership, not just the code.

Sometimes six months is too slow

Twice a year is a baseline, not permission to ignore the app between checkpoints. I would move sooner when:

• a security advisory affects code the app actually uses;
• Apple or Google announces a submission deadline the current build cannot meet;
• a critical dependency stops supporting the project's version;
• a new device or operating-system beta exposes a real failure in an important workflow; or
• the current framework or toolchain blocks a product change the business has already approved.

I would also resist upgrading just because a version number changed. If the team is in the middle of a high-risk release, the newest framework version may not be the safest immediate move. The decision should consider release timing, test coverage, dependency readiness, and what the business can responsibly absorb.

What an owner should expect from the upgrade

An upgrade is complete when the version changed and the product is still trustworthy. For a live app, I would expect the team to answer:

1. Which React Native or Expo versions are we moving from and to?
2. Which dependencies, patches, and native project files also need to change?
3. What did the release notes say could break?
4. Which customer workflows will we regression test on iOS and Android?
5. Can we still build, sign, distribute, and submit the app through the real release path?
6. What was deferred, who owns it, and when will we review it again?

That last question matters. A clean upgrade is not one where every old dependency gets solved. It is one where the team knows what remains and the business is not surprised later.

My twice-yearly recommendation is really an ownership recommendation. January and June are simply two places on the calendar where the company agrees to look at the product it depends on and decide what staying current requires.

You may need to move sooner. You may have a well-supported app that can safely move later. What I would avoid is letting a full year pass with nobody responsible for making the decision.