React Native 0.87 shares React code while keeping native ownership
React Native 0.87 lets a team write components, hooks, and application logic in React, then render through Android and iOS platform UI. Fast Refresh shortens the edit loop for JavaScript changes. Native Modules cover capabilities that the shared layer cannot reach. The practical bargain is useful code reuse without pretending that mobile platforms have become browsers.
That boundary decides whether React Native fits your team. Permissions, signing, store delivery, native SDKs, and platform-specific failures still belong to mobile engineering. Existing apps can adopt one screen or user flow at a time, which is a more controlled commitment than a rewrite. A web group with no appetite for Xcode or Android Studio will eventually hit work it cannot solve from JavaScript alone.
The 0.87 README sends most new apps through Expo
The 0.87 README recommends using a React Native framework and names Expo as the production-grade choice. Expo supplies routing, a standard library of native modules, and build tooling around React Native. That route removes several early decisions while preserving the framework underneath. For a new product, the burden of proof belongs with the bare setup.
Bare React Native makes sense when Expo conflicts with an existing native app, a specialized SDK, or a build process your mobile team already controls. You gain direct ownership of the Android and iOS projects. You also own their configuration changes. The README is unusually honest about this trade: navigation, native dependencies, and platform tooling are problems a framework has already addressed.
What happened when we ran it
Our sandbox cloned commit 99d327c with 3 CPUs, 8 GB of RAM, Node 22, no secrets, and no elevated privileges. The 58.6 MB checkout contained 7,249 files and about 873,400 lines of source. Yarn installation succeeded in 285 seconds, pulled 1,052 packages, and left 1,049 MB on disk.
The configured build passed in 26 seconds. Jest finished in 154 seconds with 6,109 tests passed, 0 failed, and 1 skipped out of 6,110. Our measurement setup proves that this commit installs, builds, and clears its supplied Node test command in a fresh Debian container. It does not measure launch time, scrolling, memory use, generated app size, or native device behavior.
Thirty-six workflows do not replace a device build
The repository had 36 CI workflow files and monorepo workspaces, although our scan found no Dockerfile or top-level tests directory. The workspace configuration still found and ran the suite. Those signals make the source tree credible for contributors, especially beside 6,109 passing tests. They say much less about an app assembled from third-party modules and its own native settings.
Our run never compiled an Android APK or an iOS application. It did not start an emulator, sign a release, or install anything on a phone. That distinction matters because the framework repository and your product have different dependency graphs. Use the 26-second build as evidence about React Native's checked-out source, then test your actual navigation, accessibility, startup, and native modules on representative devices.
Bare Android setup needs Node 22.11 and JDK 17
The version 0.87 Android guide requires Node 22.11 or newer, recommends JDK 17, and directs developers to Android Studio. Its Linux path calls for Android SDK Platform 35, Build Tools 36.0.0, an emulator or physical device, and environment variables for the SDK. The docs estimate about an hour when Android Studio or Xcode is not already installed.
Native iOS work has a harder platform limit: the same 0.87 guide requires a Mac, Xcode, its command-line tools, and CocoaPods. Linux and Windows can use Expo Go on an iOS device, but they cannot build an iOS project containing native code. No hosted credential fixes that limitation. Budget for Mac hardware or a suitable remote build path before promising both stores.
A 0.87 upgrade can change three project layers
React Native's 0.87 upgrade guide describes a typical app as an Android project, an iOS project, and a JavaScript project. Package versions are only the first step. Upgrade Helper shows generated project-file differences, and the guide tells developers to apply relevant changes manually. That is a mobile release task, especially when native modules sit on the same compatibility path.
Release 0.87.1 arrived on August 26, 2026 with Hermes, Animated typing, CocoaPods, and Swift Package Manager changes. Several fixes dealt with header paths, manifest naming, and a Hermes bytecode mismatch in SwiftPM release builds. The list is useful evidence that native packaging details receive active work. It also shows why an upgrade deserves device coverage instead of a dependency bot merge.
October activity supports adoption, while 1,156 open items demand triage
GitHub showed 126,810 stars and a last push on October 8, 2026. Its 1,156 open items split into 683 issues and 473 pull requests, so the combined repository count should not be read as 1,156 confirmed bugs. Same-day pushes, a current 0.87.1 release, and a large incoming queue describe a maintained framework with substantial support traffic.
React Native is the practical choice when React familiarity matters and someone on the team can own the native edges. The 1,049 MB install and 285-second setup are manageable for a framework this large, while 6,109 passing tests give contributors a sound starting point. Choose it for shared product work across two mobile platforms. Keep the native projects staffed, tested, and visible in every release plan.