React Native 0.87: A 10-Minute Upgrade Readiness Check

Builder brief

Format

guide

Stack

React Native

Reading time

6 min

React Native 0.87 is now the active stable release. It makes the Strict TypeScript API the default, updates the Android build baseline, raises the minimum Node.js version, and introduces changes that can expose assumptions in older projects.

This is a practical pre-upgrade check. You can run it in about ten minutes and decide whether your project is ready, needs a small preparation pass, or should stay on its current version until a dependency catches up.

The short version

Before changing the React Native version, check these five areas:

1. search for deep imports from react-native/Libraries/*;
2. confirm that your local and CI environments use Node.js 22.13 or newer;
3. audit native libraries for explicit React Native 0.87 support;
4. verify that your Android tooling is ready for AGP 9, Kotlin 2, and compileSdk 37;
5. create a clean release-build baseline and a rollback point.

If any one of these checks fails, fix it before the framework upgrade. Keeping preparation and migration as separate changes makes regressions much easier to isolate.

1. Find deep React Native imports

React Native 0.87 enables the Strict TypeScript API by default. The public API is the supported surface, while deep imports into React Native internals can break as the framework evolves.

Run a repository search such as:

rg "react-native/Libraries|react-native/src" .

Replace direct imports from internal paths with exports from react-native or with a maintained library that exposes the behavior you need. Do this before the upgrade so the change can be reviewed and tested independently.

React Native still documents a temporary opt-out, but the project says that escape hatch will be removed after 0.88. Treat it as migration time, not a permanent setting.

2. Check Node.js everywhere, not only on your laptop

React Native 0.87 requires Node.js 22.13 or newer. A local upgrade is not enough if CI, a deployment image, or another developer machine still uses an older runtime.

Check the version in:

• .nvmrc, .node-version, Volta, or the engines field in package.json;
• CI workflow files;
• Docker images;
• EAS Build or other cloud-build configuration;
• scripts that run Metro, tests, or code generation.

Pin one supported version across environments. That turns an intermittent build difference into a reproducible setup.

3. Audit native dependencies before changing the framework

The React Native package may upgrade cleanly while an older native dependency does not. List the libraries that contain iOS or Android code, then check their release notes and open issues for React Native 0.87 compatibility.

Pay particular attention to:

• navigation and screens;
• gestures and animations;
• camera, maps, notifications, and media;
• authentication and payments;
• storage and database libraries;
• custom native modules copied into the project years ago.

Remove unused native packages first. Every unnecessary module increases the surface area of the migration and the number of native build errors you may need to diagnose.

4. Verify the Android build baseline

React Native 0.87 moves the Android baseline to Android Gradle Plugin 9, Kotlin 2 or newer, and compileSdk 37. These changes can expose custom Gradle logic or third-party plugins that relied on older behavior.

Before the upgrade, record the versions currently used by the app and confirm that each custom plugin supports the new baseline. After the upgrade, build a release artifact—not only a debug build—and test startup, navigation, network requests, authentication, and any native feature that matters to the product.

5. Decide whether Swift Package Manager matters to your app

React Native 0.87 adds experimental support for building iOS dependencies with Swift Package Manager. It is an option, not a required migration for every project.

If CocoaPods is stable for your app, keep the framework upgrade focused. Test Swift Package Manager in a separate branch only when it solves a real problem for your team. Combining a dependency-manager migration with a React Native upgrade makes failures harder to attribute.

6. Create a release-build baseline

Before changing dependencies, capture the current state:

• a clean Android release build;
• a clean iOS release or archive build;
• test results;
• startup and key-screen smoke tests;
• the current lockfile;
• a Git tag or commit you can return to.

Then repeat the same checks after the upgrade. A successful development-server launch is useful, but it does not prove that the production app can be built or that native features still work.

A low-risk upgrade sequence

Use small, reviewable steps:

1. remove unused dependencies and internal imports;
2. align Node.js and build tooling across environments;
3. update native libraries while the framework version is unchanged, where possible;
4. create the release-build baseline;
5. run the official React Native Upgrade Helper diff;
6. upgrade React Native and regenerate native changes carefully;
7. run release builds and focused device tests;
8. ship to a small internal or beta group before a full rollout.

Avoid mixing this work with a redesign, navigation rewrite, or unrelated feature launch. A narrow upgrade is easier to test and safer to reverse.

Can an AI coding agent perform the upgrade?

An agent can help search for internal imports, compare configuration files, update repetitive code, and run checks. It should not be given an unbounded instruction to rewrite the whole project.

A better task is specific and verifiable:

Audit this repository for React Native 0.87 blockers. List deep imports, unsupported native dependencies, Node and Android version mismatches, and the release-build commands. Do not modify files until the report is reviewed.

Once the report is correct, let the agent implement one migration group at a time and show the diff and test output. The same rollback and release-build rules still apply.

Your go/no-go decision

Upgrade now when the critical native dependencies are compatible, the team can run both release builds, and you have time to test the app's important flows.

Prepare first when you still have deep imports, inconsistent Node versions, or custom native tooling that has not been checked against the new Android baseline.

Wait when a critical dependency has no compatible release and replacing it would create more product risk than staying temporarily on the current version. Waiting should have an owner and a date to re-check, not become an indefinite upgrade strategy.

Authoritative references

• React Native 0.87 release notes
• React Native releases overview
• React Native Upgrade Helper