React components render through native platform controls
React Native lets developers describe application interfaces with React while the runtime renders native platform views. The result uses Android and iOS controls rather than placing the whole product inside a browser view. React concepts such as components, hooks, declarative state, and Suspense carry over, and Fast Refresh applies many JavaScript changes without a complete native rebuild.
Shared code still has a boundary. Platform behavior, native SDKs, build systems, permissions, signing, and store delivery remain Android and iOS concerns. When JavaScript cannot reach a required capability, Native Modules connect it to Swift, Objective-C, Java, Kotlin, or C++. That escape hatch is a strength for a staffed mobile team and a warning for a web team expecting native work to disappear.
The project also supports incremental adoption. An existing native application can embed React Native for selected screens instead of committing to an immediate rewrite. This is often the more credible path for a mature app because release risk stays contained. The cost is a mixed architecture that requires engineers to understand the boundary and debug both sides.
What happened when we ran it
Our sandbox cloned commit d83d106 into an unprivileged Debian container with 3 CPUs and 8 GB of RAM. The 57.6 MB checkout contained 7,141 files and about 850,464 lines of source. Yarn installation succeeded in 223 seconds, adding 1,045 packages and occupying 964 MB on disk.
The configured build succeeded in 14 seconds. Tests then completed successfully in 112 seconds: Jest reported 5,845 passed, 0 failed, and 1 skipped out of 5,846. This is the cleanest measured result in this review set, and it came from the exact commit named above rather than a release badge.
The repository has 29 CI workflow files and uses monorepo workspaces. Our scan found no Dockerfile and no top-level tests directory, yet the test command found and ran the suite through workspace configuration. We did not build an Android APK, compile an iOS application, run an emulator, or measure interface performance. Passing JavaScript tests does not answer those separate questions.
Expo is the default recommendation for a new app
React Native's own README tells most developers to start through a framework. It names Expo as the recommended path and points to its file-based routing, standard native-module library, and platform tooling. That guidance matters because a bare renderer does not settle navigation, updates, permissions, dependency linking, or the many choices a production mobile app accumulates.
Starting without a framework remains supported. It makes sense when Expo's abstractions conflict with an existing native application, a special build pipeline, or a platform capability the team already owns. The price is more direct responsibility for native project files and dependency integration. A team should choose this route because it needs the control, not because fewer abstractions sound cleaner on day one.
The 964 MB dependency result also belongs in local planning. It does not include every Android SDK, emulator image, Xcode component, or application dependency a real product may add. CI caches, developer laptop storage, and fresh onboarding all feel that weight. The 223-second install was acceptable in our container, but it was not a complete mobile environment setup.
Native modules keep the ceiling high and the debugging split
React Native primitives cover common mobile UI and accessibility behavior. The surrounding package ecosystem extends that base, while Native Modules provide direct access when no suitable package exists. Teams can keep shared product logic in JavaScript and write a narrow platform bridge for specialized work such as an SDK supplied only for iOS or Android.
Every native dependency adds another compatibility axis. A library may need changes when React Native, Gradle, Android, Xcode, CocoaPods, or a platform SDK moves. Bugs can cross the JavaScript and native boundary, which makes a browser-only debugging habit insufficient. Keep at least one engineer comfortable opening both native projects and reading build logs from each platform.
Release 0.87.0 was published on August 11, 2026. Its GitHub page points users to the Upgrade Helper, a full changelog, and a separate release issue tracker. That structure is useful because upgrades often involve generated native-project changes, not only a package version. Treat each framework jump as a mobile release with device coverage rather than a routine JavaScript bump.
Current activity and 5,845 passing tests support adoption
GitHub recorded the last push on August 26, 2026, with 126,409 stars and 1,094 open issues and pull requests combined. The large queue is unsurprising for a framework spanning two major operating systems, native languages, JavaScript, C++, and many downstream integrations. It is evidence of support demand and ongoing work, not a count of confirmed defects.
The repository evidence is convincing: a 14-second build and 5,845 passing tests from our sandbox give contributors a much better starting signal than badges alone. Product evidence still has to come from a representative app on real devices. Test startup, navigation, accessibility, memory, offline behavior, upgrades, and the native modules your release actually depends on.
React Native is an easy recommendation for a React-heavy organization that treats mobile as its own engineering discipline. It is a poor promise for management that expects identical behavior everywhere from one JavaScript team. The framework shares a great deal of code, while the remaining native work is precisely the part that needs experienced ownership.