React Native 0.87 Released: Strict TypeScript API by Default, Node.js 22 Required
React Native 0.87 is the current stable version of the framework. The project's release announcement is dated August 11, 2026, and its headline items are a new default set of TypeScript definitions, a faster Metro bundler, experimental Swift Package Manager support on iOS, and support for version 9 of the Android Gradle Plugin.
For a company that owns an app built through React Native development, two details matter more than the feature list. The release raises the minimum versions of the tools needed to build the app, and it pushes version 0.84 out of the supported window. An app that has not been upgraded since early 2026 is now on a version the project no longer maintains.
This article explains what is stable, what is experimental, what has been removed, and how to decide when to upgrade.
What is in React Native 0.87
The announcement groups the release into four highlights. Three are available for production use now: the Strict TypeScript API as the default, an updated Metro bundler, and Android Gradle Plugin 9 support. The fourth, Swift Package Manager support for iOS, is explicitly experimental, and the post tells readers not to use it in production yet.
Unlike version 0.86, which the React Native team described as having no user-facing breaking changes, 0.87 does remove and change APIs. That makes it a release to plan for rather than apply casually.
The Strict TypeScript API is now the default
TypeScript definitions describe to a developer's tools what each part of React Native accepts and returns. They catch mistakes before the app runs. Until now, React Native's definitions were maintained by hand alongside the code. According to the announcement, the Strict TypeScript API, first offered as an opt-in preview in version 0.80, is now the default, and its definitions are generated directly from React Native's source code so they cannot drift from what the framework really does.
The consequence is that code which reached into React Native's internal files stops passing type checks. The post states that so-called deep imports into internal paths are now type errors, and that some type names and shapes have changed where the old definitions were inaccurate. Your own code may be clean and still be affected, because older third-party libraries are a common place for deep imports.
A temporary opt-out
The announcement documents a configuration setting that restores the legacy definitions. It describes this as a temporary bridge that remains available through React Native 0.88, and says the team intends to remove the legacy types in the release after that. That later removal is announced, not yet released. The opt-out is useful for getting an upgrade through without rewriting everything at once, but it is not a place to stay.
Faster Metro, and Swift Package Manager as an experiment
Metro is the tool that packages an app's JavaScript. The React Native team reports that in this release source map generation is twice as fast and that Metro uses half as much memory. Those are the project's own figures; we have not measured them independently. The practical effect is on developer tooling and build machines, not on how fast the app runs for customers. Metro also drops support for some older configuration file formats, which is a small check for the upgrade.
On iOS, 0.87 adds an opt-in way to manage native dependencies with Swift Package Manager in place of CocoaPods. The post is clear about its status: CocoaPods remains the default and supported route, the commands and generated project layout may change in later releases, and community libraries need to ship their own package definitions before they work with it. It is a signal of direction, and nothing a business needs to act on today.
New minimum requirements for building your app
The announcement lists the following toolchain changes. These affect developer laptops and, more importantly, the automated build service that produces your store releases.
- Node.js 22.13.0 or later is required.
- On Android, the minimum Kotlin version is 2.0, and Kotlin 2.2.0 is bundled.
- On Android, libraries must compile against SDK 34 or later, and React Native's own compile SDK and build tools move to 37.
- Android Gradle Plugin 9 is supported for the first time, with a recommendation to switch off two of its newer options (built-in Kotlin and the new DSL) in the project's Gradle properties for now.
None of this changes which phones your app runs on. It changes what has to be installed to build it. Build pipelines pinned to an older Node.js version will fail until they are updated.
APIs removed in this release
The post lists a number of removals. The ones most likely to appear in an existing codebase are InteractionManager, for which the team points to requestIdleCallback as the replacement; several StatusBar properties, including background color and translucency settings; and the animated property on Modal. The standalone react-devtools connection has also been removed in favor of React Native DevTools.
A second list covers deprecations, which still work but are marked for future removal. These include the ImageBackground component and, on Android, DrawerLayoutAndroid. A developer can search the codebase for each name in a few minutes, which makes this one of the cheaper parts of the upgrade to estimate.
Which versions are still supported
The announcement states that 0.87 is now the latest stable version and that 0.84.x moves to unsupported. The project's releases overview explains the policy behind this: the latest three minor series are supported. At the time of writing, that page lists 0.87 and 0.86 as active, 0.85 as "End of Cycle", and 0.84 and earlier as unsupported.
The same page shows version 0.88 with a scheduled release date of October 12, 2026. That is a planned date and may move. If it holds, the supported window shifts forward again and 0.85 drops out.
For teams using Expo, the announcement says 0.87 is available through Expo's canary releases. It does not name a stable Expo SDK version, so Expo-based projects should check Expo's own release notes before planning.
What this means for your business
The points below are our interpretation and are meant as guidance. Unsupported does not mean broken. An app on 0.84 or earlier keeps working on customers' phones. What changes is that fixes from the React Native project will no longer be released for that version, so a problem caused by a new iOS or Android release would have to be solved by upgrading under time pressure.
React Native ships a new minor version roughly every two months, as the dates on the releases page show. Apps that upgrade every release or two face small steps. Apps that skip a year face several sets of breaking changes at once, and the cost of that jump is driven mostly by the number and age of third-party libraries, not by your own screens. If you are still deciding on a framework, our comparison of native, Flutter and React Native covers this maintenance trade-off in more detail.
What to do next
Start by asking your developers which React Native version the app uses and whether it is inside the supported window. If it is on 0.85 or older, plan an upgrade to 0.87 now instead of waiting for 0.88. Ask for a dependency audit that flags libraries using deep imports or removed APIs, and confirm that your build service can run Node.js 22.13 or later. Treat the TypeScript opt-out as a short-term aid with a known end, and leave Swift Package Manager alone until the project declares it ready for production.
Conclusion
React Native 0.87 makes the Strict TypeScript API the default, speeds up Metro, raises build tool requirements including Node.js 22.13, removes several long-deprecated APIs, and moves 0.84 out of support. With 0.88 scheduled for October 12, 2026, the gap between an unmaintained app and the current version widens every two months.
If you would like an estimate for bringing an older React Native app up to date, you can request a quote. Entrant Technologies builds websites, web applications, mobile apps and custom software.