Mobile apps
Upgrading an older React Native app
The framework is usually the easy part. An old React Native app is hard to upgrade because of its libraries and of the architecture change completed in 0.82. Sort out those two things first, and the version number follows.
By itmarkerz Technologies. Updated 30 October 2026.
Where things stand
React Native’s release policy maintains the latest 3 minor series, and new versions arrive about every two months. The milestones below, taken from the React Native blog, are the ones that shape an upgrade plan.
| Version | Released | What changed |
|---|---|---|
| 0.76 | October 2024 | New Architecture on by default |
| 0.80 | June 2025 | Legacy Architecture frozen; warnings for APIs that will stop working |
| 0.82 | October 2025 | “The first React Native that runs entirely on the New Architecture” |
| 0.84 | February 2026 | Hermes V1 by default; further removal of legacy components |
| 0.87 | August 2026 | Strict TypeScript API by default |
| 0.88 | October 2026 | Latest release when we checked |
The order we would work in
- Make a list of native dependencies. For each one, note its last release, and whether it supports the New Architecture. An abandoned library with native code is the most likely thing to block you. Decide whether to replace, fork or remove it.
- Add a safety net. Write down the flows that earn money or would generate complaints. Automate what you can, and otherwise keep a written test script to run on real devices at every stage.
- Bring your build tools up. Node, Xcode, Android Gradle Plugin and the target SDK levels the stores now require are often the first failures, and they have nothing to do with your code.
- Move in stages. Go through the milestones above rather than directly to the latest. Use the Upgrade Helper, which shows all file changes between two versions. On Expo, move one SDK at a time.
- Handle the architecture step on its own. Do this at a version where the old architecture can still be switched back, if yours allows it, so that you can compare behaviour. Check native modules and third-party UI components most carefully.
- Release to a small group. Use TestFlight and a Play staged rollout, and watch crash reports before going wider.
What tends to take the time
| Area | Why it is slow | Find out early by |
|---|---|---|
| Abandoned native libraries | They may need replacing, with screens changed to suit | Listing them with their last release date |
| Custom native modules | They may need rewriting for the New Architecture | Reading your android and ios folders for custom code |
| Patched packages | Local patches may not apply any more | Checking for patch-package, and asking why each exists |
| Navigation or animation libraries | Major versions may change their APIs across the app | Searching how many screens use them |
| Store requirements | New target levels and privacy declarations | Reading the current store requirements |
| No tests | Each stage needs manual checks | Timing one full manual pass |
Don’t forget the API and the users
People on older builds will keep calling your API, so don’t remove what they use on the day you release. If your app has no minimum-version check, add one in this upgrade, because it makes future changes much safer. We explain this in one Laravel API for web and mobile. Also consider whether this is the moment to adopt Expo’s generated native projects, since doing so will make later upgrades easier.
Afterwards, schedule upgrades as a routine. With a release about every two months and only three series maintained, falling behind happens quickly, and small regular steps cost much less than a project like this one.
React Native work in our portfolio
UK garage-booking SaaS: car owners book, pay, receive invoices and reminders from their phone; garages manage services and slots. Laravel API, Next.js web app, React Native iOS/Android apps. About one year.
- Sector
- Automotive
- Region
- UK
- Stack
- Laravel, Next.js, React Native
- Engagement
- Product build, about one year
Questions
Which React Native versions are supported?
React Native maintains the latest 3 minor series. The current release checked on 30 October 2026 is 0.88, with releases about every two months. So a version from a year ago is already out of support. Check the releases page, because this changes quickly.
Can we skip versions?
The Upgrade Helper will show a diff between any two versions, so a single jump is possible on a small app. On an app that is far behind, we would rather go in stages around the big changes, because a failure then has fewer possible causes. Expo's advice is one SDK version at a time.
Should we rewrite instead?
Sometimes. If the app is small, untested and depends on many abandoned libraries, a rebuild could be cheaper, and your API doesn't have to change. Get a list of libraries and their status before you decide.
More on mobile apps
- Wrapped web app or React Native? We've shipped bothA decision table from a three-month wrapped app and a year-long React Native SaaS.
- One Laravel API, web and mobile: how we structure itOne API for a Next.js site and React Native apps, without two sets of rules.
- Getting a wrapped app through store reviewWhat Apple and Google publish about repackaged websites, and what to build.
- Expo or bare React Native?What React Native's own docs recommend, and when you'd still manage native folders.
Is your app stuck on an old version?
Send us your package.json and tell us which version you are on. We will tell you which libraries are likely to be the problem.
We reply within one business day (IST).