React Native 0.87: What’s New, Breaking Changes & Upgrade Guide

React Native 0.87 is not a flashy reinvention of the framework. It is something more valuable for teams shipping real products: a release focused on making the development foundation more predictable.

The update makes React Native’s Strict TypeScript API the default, moves Metro forward with meaningful speed and memory improvements, introduces an experimental path away from CocoaPods, and prepares Android projects for the latest generation of the Gradle toolchain.

There are breaking changes, so this is not an upgrade to merge casually on a Friday afternoon. But the direction is clear. React Native is tightening its public contracts, modernizing its build systems, and reducing the accidental complexity that has followed the ecosystem for years.

The headline: React Native now has a clearer public API

The most important change in 0.87 is the arrival of the Strict TypeScript API as the default.

Until now, React Native’s TypeScript definitions were maintained separately from much of the underlying source. That could create gaps between what the types promised and what the framework actually implemented. The new approach generates public types directly from React Native’s source, improving accuracy and reducing that drift.

This also draws a firmer boundary around the supported JavaScript API. Imports from the root react-native package are the public contract; internal paths are not. Deep imports such as react-native/Libraries/*, already discouraged in earlier releases, now produce type errors under the Strict API.

For teams that cannot migrate immediately, 0.87 still includes a temporary opt-out. The React Native team says that bridge will remain through 0.88, with the legacy TypeScript definitions intended for removal in the following release. In other words, opting out buys time, not a permanent exemption.

Metro gets faster—and uses less memory

React Native 0.87 upgrades Metro from 0.84 to 0.87. The practical gains are easy to understand:

• Source-map generation is reported to be twice as fast, which should reduce the wait when React Native DevTools loads debugging information.

• Metro uses roughly half the memory for source-map storage.

• TypeScript and ECMAScript module configuration files, including metro.config.mts, are now supported as stable options.

• Package self-resolution and other resolver improvements give modern package layouts better support.

Metro is also cleaning house. YAML configuration files and JavaScript configuration files using the .es6 extension are no longer supported. Most projects will not notice these removals, but teams with older or highly customized setups should check their configuration before upgrading.

Faster source maps may sound like an incremental optimization, yet it affects one of the most repeated actions in a developer’s day: moving from a running app to useful debugging information. Small improvements in that loop compound quickly across a team.

Swift Package Manager support points to a simpler iOS setup

React Native 0.87 introduces experimental support for Swift Package Manager, or SwiftPM, as an alternative way to manage native iOS dependencies.

The appeal is obvious. A SwiftPM-based project can rely on Xcode without requiring Ruby, Bundler, or CocoaPods. React Native consumes the same prebuilt XCFrameworks it already publishes, while a command adds Swift package references to the existing Xcode project. Signing settings, capabilities, and build phases remain in place.

There is also less ceremony after the initial setup. When a native dependency changes, the project can detect it and run autolinking during the build instead of asking developers to remember a separate pod install step.

However, the word “experimental” deserves emphasis. CocoaPods remains the default and supported production path. Community libraries need a Package.swift, fresh clones and CI environments require a setup command before building, and the commands or generated project structure may change in future versions.

The takeaway is not “remove CocoaPods today.” It is that React Native now has a credible route toward a more native, Xcode-centered dependency workflow. Library maintainers should start paying attention, and adventurous teams can begin testing it outside production.

SwiftPM support also changes how React Native packages precompiled headers. Native code using a bare import such as:

#import <RCTAppDelegate.h>

may need to use the namespaced form:

#import <React/RCTAppDelegate.h>

This is a small edit, but an important one to include in migration checks for apps with custom native iOS code.

Android moves to AGP 9

On Android, React Native 0.87 adds support for Android Gradle Plugin 9. AGP 9 brings substantial changes to the wider Android build ecosystem, and React Native is adopting it with a transitional configuration.

For this release, the recommended setup disables AGP 9’s built-in Kotlin and new DSL behavior in android/gradle.properties:

android.builtInKotlin=false
android.newDsl=false

These switches give the React Native ecosystem time to adapt. They are transitional rather than long-term settings; the current plan is for the opt-outs to disappear with AGP 10.

The broader Android and JavaScript toolchain requirements also move forward:

• Node.js 22.13 or newer is required.

• Kotlin 2.0 or newer is required, with 2.2 bundled by default.

• Android libraries must compile against at least API level 34.

• The default compile SDK and build tools move to API level 37.

These updates will matter most in monorepos, custom Gradle builds, native modules, and CI images where tooling versions are pinned. Review those environments before changing the React Native dependency itself.

Breaking changes worth checking first

The Strict TypeScript API is the largest migration item, but it is not the only one. A few removals are especially likely to appear in mature applications:

• InteractionManager has been removed; use requestIdleCallback for deferred work.

• The deprecated animated prop on Modal is gone.

• Deprecated StatusBar props—including backgroundColor and translucent—and their setters have been removed.

• ScrollView no longer accepts boolean values for keyboardShouldPersistTaps.

• useColorScheme() now returns ColorSchemeName | null; it no longer returns unspecified.

• The old rn-get-polyfills entry point is gone in favor of @react-native/js-polyfills.

• Connecting to the standalone react-devtools package over WebSocket is no longer supported; React Native DevTools is now the expected path.

React Native 0.87 is a maturation release. It replaces fuzzy API boundaries with generated, source-aligned types. It reduces bundler overhead. It begins exploring an iOS dependency workflow that fits naturally inside Xcode. And it keeps pace with Android’s rapidly evolving build stack.

To read more about update read from official react native release article https://reactnative.dev/blog/2026/08/11/react-native-0.87