React Native upgrades are becoming architecture work
React Native 0.87 was released on 11 August 2026 with the Strict TypeScript API enabled by default, Metro 0.87, experimental Swift Package Manager support for iOS and first support for Android Gradle Plugin 9. The release also raises minimum tooling expectations around Node.js, Kotlin and Android build configuration.
For product teams, the message is clear: a mobile app upgrade is no longer only a package version change. It touches type safety, imports, native dependencies, CI images, Android Gradle behavior, iOS package strategy and release confidence. That makes the upgrade valuable, but it also means it deserves a small project plan.
Audit the app before changing versions
A safe upgrade starts with an inventory of where the app is fragile today. Look for deep imports from React Native internals, custom Metro configuration, native modules with older headers, Android build logic that depends on deprecated APIs and release scripts that assume older Node or Gradle versions.
The goal is not to predict every error. It is to know which parts of the app are likely to fail for technical reasons and which parts would hurt users if they regress. A customer portal, field app or operational dashboard should have a different upgrade checklist than a simple content app.
- List current React Native, React, Expo, Node, Xcode, Gradle, AGP and Kotlin versions.
- Search for imports from `react-native/Libraries/*` and other private paths.
- Mark native modules that touch AppDelegate, headers, build phases, permissions or background tasks.
- Confirm which devices, OS versions and authenticated workflows must pass before release.
- Separate upgrade blockers from cleanup tasks that can wait.
Treat the Strict TypeScript API as a product quality signal
The Strict TypeScript API makes React Native's public JavaScript API the default source of truth. That can expose old assumptions: private imports, inaccurate ref types, deprecated aliases or utility paths that worked only because legacy type definitions were permissive.
This is useful friction. When the type system complains, it often points to code that could break in a future release anyway. Teams should migrate toward root exports and supported types instead of hiding every error behind a temporary opt-out. The opt-out can be helpful for staged delivery, but it should have an owner and removal date.
Check Metro changes against developer experience
Metro 0.87 promises faster source map generation and lower memory usage, both of which matter in large apps where debugging time quietly becomes delivery cost. The same upgrade also removes support for older config formats and tightens expectations around modern TypeScript and ESM configuration.
A good engineering check is practical: run the app, trigger the heaviest screens, open React Native DevTools, verify source maps, and compare local startup and reload behavior. If developers spend less time waiting and more time debugging real app state, the upgrade is already paying back.
Keep Swift Package Manager experimental until proven
React Native 0.87 adds an opt-in Swift Package Manager path for iOS. It is attractive because it can reduce the Ruby, Bundler and CocoaPods surface in some workflows, but React Native still describes CocoaPods as the default supported path and warns that commands and generated layout may change.
That makes SwiftPM a controlled experiment, not a default migration for production apps. Try it on a branch, measure CI setup, verify native dependencies, test fresh clone behavior and keep a rollback path. For apps with many third-party native packages, the real question is whether the whole dependency graph is ready.
Plan Android Gradle Plugin 9 as its own workstream
AGP 9 is a major Android build change with new public DSL interfaces and compatibility requirements. React Native 0.87 adds first support for it, while Android documentation recommends using the upgrade assistant and checking behavior changes carefully.
For a mobile product, Android build work should not be hidden inside the JavaScript upgrade. CI images, JDK, Gradle wrapper, Kotlin version, compile SDK, library compatibility and release signing all need explicit verification. A green local debug build is not enough if the release pipeline still uses older assumptions.
Coordinate Expo projects by SDK cadence
Expo teams should read the React Native release through the Expo SDK roadmap rather than upgrading blindly. Expo SDK 55 shipped with React Native 0.83 and removed Legacy Architecture support for SDK 55 projects and later, while React Native 0.87 was initially positioned for canary availability in Expo.
That means Expo apps need two plans: one for the SDK migration path and one for product QA. Development builds, EAS Update behavior, native module compatibility, over-the-air update strategy and store submission timing all shape the safest release window.
A practical upgrade plan for production apps
For EDS Labs mobile projects, the strongest React Native 0.87 upgrade path is staged and evidence-based. Start with dependency and import audits, update tooling in CI, run the upgrade helper, fix Strict API errors, verify native builds, then test the highest-value user flows on real devices or representative simulators.
The business result is a mobile app that stays current without turning release week into an emergency. The upgrade becomes a way to reduce hidden technical debt, improve type confidence, speed up debugging and keep native platform requirements under control.