What is the most common upgrade mistake?

Jumping several React Native versions in one go without stabilising builds first. Teams lose weeks to native project drift they cannot bisect.

How much automated testing do we need?

Perfect coverage is rare. A reliable typecheck, lint, unit tests on critical logic, and a short device smoke suite on CI catch most upgrade regressions.

Should we upgrade iOS and Android together?

Same React Native version, but native toolchain fixes often land one platform at a time. Ship internal builds per platform before store submission.

When should we pause an upgrade?

When crash rates rise without a fix, store review blocks you, or a native vendor SDK has no compatible release. Document the blocker and finish stabilisation work first.

React Native Upgrade Checklist

Upgrading React Native in production is a release management problem as much as a coding task. This checklist is what we walk through with UK teams before bumping major versions. Adapt it to your compliance rules and store policies.

Before you change versions

Confirm supported Node, Xcode and Android Studio versions for your target React Native release. Snapshot current crash-free rates and core flow timings. Tag production builds clearly in your crash tool so comparisons stay honest.

Freeze unrelated refactors on the upgrade branch. Communicate blackout dates to product and support. If you cannot ship a patch from main today, fix that before touching React Native.

Dependencies and JavaScript layer

Upgrade React and community packages in steps recommended by the upgrade helper where possible. Watch navigation, reanimated and gesture libraries; they often lag core releases. Run typecheck and tests after each meaningful bump instead of one giant merge.

Remove unused packages. They still compile native code and confuse future upgrades. Replace abandoned modules early; waiting until the final React Native bump wastes time.

Android native project

Review Gradle, compile SDK, Kotlin and NDK requirements in release notes. Update signing configs in a branch tested on CI, not only on a lead developer’s machine. Check Proguard or R8 rules if you minify.

Run internal builds on low-end devices common among your users, not only flagship phones. Permission changes between Android versions break flows that QA on emulators misses.

iOS native project

Update minimum iOS version deliberately; dropping old OS support saves pain but may affect enterprise users. Review Podfile conflicts after pod install. Watch for Apple privacy manifest requirements on third-party SDKs.

Test background modes, push notifications and deep links on physical devices. Simulators hide entitlement issues until TestFlight.

CI, testing and artefacts

CI must produce signed artefacts on every merge to the upgrade branch. Add smoke tests that launch the app, log in, and complete one purchase or booking flow if applicable. Keep artefacts for bisect when crashes appear.

Document how to run the same builds locally in README steps that a new hire can follow. Drift between CI and laptops causes “works on CI” dead ends.

Rollout, monitoring and rollback

Ship to internal testers first, then a small production percentage if your store supports it. Watch crash clusters, ANRs and API error rates for 24–48 hours before full rollout. Define rollback: previous store version, feature flags, and any server compatibility requirements.

Prepare support macros for known visual glitches so customer teams respond consistently. Even minor UI shifts generate tickets if users are surprised.

After upgrade lands

Schedule the next minor bump while lessons are fresh. Pay down native debt you discovered. Update runbooks for on-call engineers with new build commands and common failure fixes.

Share a short retrospective with stakeholders: what slowed the upgrade, what tooling helped, and which modules to replace before the next cycle.

For hands-on help, see our React Native modernisation service or book a discovery call to review your checklist against your codebase.

Putting this into a programme

Translate the guidance above into tickets your team can schedule. Break upgrades into releasable slices with acceptance criteria tied to crash rates or core user flows, not only merged pull requests. Review progress weekly with product so scope creep is visible early.

If internal capacity is thin, pair external senior engineers with your developers rather than outsourcing silently. Knowledge transfer happens in reviews and pairing sessions, not in a final PDF alone.

When you are ready for an independent review of your app or platform, book a discovery call or email hello@algobots.co.uk with context. We will suggest a proportionate next step.

What we need from your side

Access to repositories, CI, crash reporting and someone who knows recent release history. Product input for prioritisation and a single decision maker for scope changes keeps momentum. Security reviews are normal for enterprise clients; we provide statements of work and can work with your IT contacts.

We align with your sprint cadence where possible. Fixed-date marketing launches still happen; tell us early so upgrade work does not collide with immovable deadlines. Honesty about trade-offs protects customers and staff.

Most programmes benefit from a short retrospective after the first milestone. Capture what to repeat and what to fix in tooling. That habit pays back on the next upgrade cycle.

We publish no vanity metrics on this site. Outcomes depend on your starting point, team capacity and how boldly you fund maintenance alongside features.

Record decisions in your wiki or ADRs as you go. Future upgrades are cheaper when the last one was documented honestly, including dead ends.

If several teams depend on the same release train, nominate one upgrade coordinator who tracks blockers across iOS, Android and backend. That role prevents silent assumptions about who owns store submission each week.

React Native Upgrade Checklist for Production Applications