React Native 0.87 shipped on August 11, 2026, and it is the release where the framework's public API stops being a moving target. The headline is that the Strict TypeScript API is now the default for every project, which reads like a typing detail and is actually the clearest signal yet that a 1.0 with real API stability is close. For a studio shipping premium React Native apps, the question this week is simple. Upgrade now or wait, and what does the move actually cost.
What shipped in React Native 0.87
React Native 0.87 makes the Strict TypeScript API the default, updates Metro to 0.87, adds experimental Swift Package Manager support, and supports Android Gradle Plugin 9, per the official release post. It landed August 11, 2026 with 265 commits from 74 contributors, and it raises the floor on the toolchain underneath your app. The new minimums are Node.js 22.13, Kotlin 2.0 with 2.2.0 bundled, and Android compileSdk 34. None of those numbers are exotic on their own. Together they mean the upgrade is not just a JavaScript bump, it is a build-environment bump that your CI images and native modules have to keep pace with. That framing matters because the temptation with a minor release is to treat it as a one-line change in package.json. This one is not.
Strict TypeScript API: what breaks and what is free
The Strict TypeScript API generates types straight from React Native's source instead of hand-maintained definitions, so the types finally match the runtime, but any deep import breaks. This is the part to plan around. Imports into react-native/Libraries/* are now type errors, the deprecated *Properties aliases such as ViewProperties are gone in favor of their *Props equivalents, and the old NativeMethods interface is replaced by HostInstance. There is an escape hatch that restores legacy deep-import resolution, but it is only available through 0.87 and 0.88, per the release notes. Treat that as a deadline, not a reprieve.
The other side of the ledger is genuinely free. If your app imports only from the react-native root, which is how most well-kept codebases are written, you inherit more accurate types with no code change, including dedicated ref instance types like ViewInstance and TextInputInstance where the old definitions were vague. Metro is the same story. It moves from 0.84 to 0.87, generates source maps twice as fast, and uses half the memory it did before. You get that performance the moment you upgrade, with nothing to rewrite. So the honest read on 0.87 is not "breaking release" or "free release." It is a release where the cost is concentrated entirely in one place, your deep imports, and everything else is upside.
Why an API freeze matters for premium mobile work
Version churn has been the real tax on React Native, and 0.87 is the framework paying it down on purpose. For years every minor release nudged the type definitions, quietly broke a deep import, or shifted a native build detail, and a studio maintaining several client apps absorbed that as a standing maintenance line. Generating types from source and making the strict API the default kills a whole category of that drift, because the types can no longer disagree with the runtime. That is worth more to a React Native practice than any single new component, since predictable upgrades are what let you quote a maintenance retainer honestly instead of padding it against surprises.
The forward signals in this release point the same way. Swift Package Manager support arrives experimental and additive, with CocoaPods still the default, which is how React Native usually introduces a major iOS build change before committing to it. TurboModules are now always on, the useTurboModules feature flag is gone, and that removes one more branch of "which architecture is this app on" from every upgrade conversation. Read together, the strict API default, the SwiftPM groundwork, and the New Architecture becoming non-optional are three moves toward a 1.0 that behaves like a stable platform rather than a fast-moving library. For teams building for uneven devices and networks across Southeast Asia, a mobile stack that stops moving under you is not a luxury. It is what makes a two-year app roadmap credible.
What we would change this quarter
Run the 0.87 upgrade on a throwaway branch this month and let the TypeScript compiler surface every deep import, because that error list is the most honest map of your framework tech debt you will get for free. Three concrete moves follow. First, fix the deep imports now rather than reaching for the legacy resolution flag, since that flag expires at 0.88 and any code leaning on it becomes an urgent problem one release later. Second, budget the toolchain bump as its own task: Node.js 22.13, Kotlin 2.0, AGP 9 and compileSdk 34 all need to be true in your CI at once, and a stale build image is where these upgrades usually stall. We treat that pipeline work as systems and automation, not an afterthought, because a mobile team that upgrades by hand eventually skips a version and pays double. Third, adopt the Metro gains immediately and leave Swift Package Manager in a spike branch, not production, until it graduates from experimental. The pattern here is the one that separates a maintained app from a stalled one. You upgrade deliberately, on your schedule, while the changes are small, instead of discovering three versions of drift the day a client asks for a new feature.