Upgrading React Native from 0.73 to 0.82: a survival guide

Upgrading React Native across one minor version is routine. Upgrading across nine - from 0.73 all the way to 0.82 - is a project, and I treated it like one. This is the war story and the playbook, because "how do I do a big React Native upgrade without losing a month" is a question I get asked a lot, and the answer is more about strategy than about any single fix.

The first decision: incremental, not big-bang#

The tempting move is to jump straight from 0.73 to 0.82 in one heroic pull request. Don't. I learned to go one or two minors at a time, getting back to a building, running, tested app at each step.

The reason is debuggability. When you jump nine versions at once and the app won't build, you have nine versions' worth of breaking changes tangled together and no idea which one caused what. Going incrementally, each step has a small, knowable set of changes. When something breaks, you know it's in this hop, and the changelog for this hop is short. It feels slower and it's dramatically faster, because you're never debugging a mystery with nine suspects.

So the real shape was: 0.73 → 0.74 → 0.75 → 0.76 → ... each one a working checkpoint before the next.

The upgrade-helper is non-negotiable#

The single most useful tool is the React Native Upgrade Helper - it shows the exact diff of the template native files between any two versions. Across this many versions, the iOS and Android project files, Gradle config, Podfile, and various config files all drifted. The helper tells you precisely what changed in those scaffolding files so you can apply the same changes to your app, which has diverged from the template over time.

You can't just take the new files wholesale (your app has its own native customizations), so it's a manual reconciliation - but the helper turns "what am I even supposed to change" into a concrete diff to work through.

Dependencies are the real work#

Honestly, most of the pain in a big RN upgrade isn't React Native itself. It's your native dependencies. Each one has its own compatibility matrix, and a library version that was fine on 0.73 may not build on 0.80.

What worked:

• Inventory every native dependency and its RN compatibility before starting. Anything unmaintained is a risk flag - you may need to replace it, which is its own mini-project.
• Upgrade libraries alongside React Native, roughly in step, rather than all at the end. A library expecting a newer RN, on an old RN, fails in confusing ways and vice versa.
• The unmaintained ones are your real timeline. One abandoned library that won't build on the New Architecture can gate the entire upgrade. Find those early so they don't ambush you at version 0.80 after weeks of work.

Turning on the New Architecture#

A major reason to push to current is the New Architecture, which is the default in this range. Flipping it on was its own phase, after the version bumps landed:

• Confirm every native dependency supports it (the same audit, with a New-Architecture lens).
• Convert your own custom native modules to TurboModules.
• Test rendering-heavy and native-interop screens hard, on real devices, both platforms - Fabric changes rendering, and the edge cases are visual and behavioral, not things a unit test catches.

I did this as a distinct step rather than mixing it into the version bumps, so that if something broke I knew whether it was "this RN version" or "the New Architecture," not both at once.

The specific things that bit#

A sampler of what actually broke, to set expectations:

• Native project file drift - Gradle and Podfile settings that the template changed and our app hadn't. The upgrade helper diff was how I found each one.
• A couple of libraries that needed major-version bumps with their own breaking changes, so the RN upgrade dragged dependency upgrades along with it.
• Build tooling versions - JDK, Gradle, CocoaPods, Xcode expectations shifted across the range and had to move with it.
• Deprecation warnings that became removals. Things deprecated early in the range were gone by the end. Going incrementally meant I saw the deprecation warning in the version that added it, with time to fix it before the version that removed it - which is exactly the argument for not big-banging.

The playbook, condensed#

1. Go one or two minor versions at a time; return to a working, tested app at each checkpoint.
2. Use the upgrade-helper diff to reconcile the native scaffolding at each hop.
3. Audit native dependencies up front; upgrade them in step; treat unmaintained ones as the real risk.
4. Do the New Architecture switch as its own phase, after the version bumps.
5. Test on real devices, both platforms, at every checkpoint - not just at the end.

It's not glamorous and there's no shortcut that makes nine versions feel like one. But done incrementally it's steady, predictable work rather than a month-long mystery, and you come out the other side current, on the New Architecture, and with a much better map of your own app's native layer than you had going in.