React Native 0.87: What the C++ Core Means for App Teams

What React Native Actually Solves

React Native solves a specific cost problem: writing the same app twice, once for Android and once for iOS. Instead of two native codebases, you write UI logic in React, and the framework renders it with the platform's own views. The README states that primitives render to native platform UI, so gestures, text scaling, and accessibility behave the way users expect on each OS. That is the core promise. The target audience is teams that already know React and want to ship a mobile app without learning Swift and Kotlin from scratch. It is not for teams that want a web wrapper; the output is genuinely native, not a webview.

The Architecture: JavaScript Logic, Native Rendering

The repository is primarily C++, which tells you something about where the work goes. The JavaScript you write runs in a JavaScript engine, and the UI is rendered by native components. The README's phrase "written in JavaScript, rendered with native code" is the whole model. The framework bridges the JavaScript thread and the native threads. Recent versions have been moving more of that bridge into C++ to improve performance and consistency across platforms. The release cadence shows active maintenance: v0.87.1, v0.86.3, and v0.87.0 all landed within a month. The architecture overview in the docs covers the current and legacy rendering paths, but the README itself does not detail the bridge internals. What you can confirm is that the core is now C++, which means the heavy lifting is shared between Android and iOS, not duplicated.

Getting Started: Framework First, Bare Metal Second

The README is explicit about the recommended path: use a framework, specifically Expo. The command is `npx create-expo-app@latest`. That is the official starting point. The README says most developers benefit from a framework because navigation, native dependencies, and platform tooling are problems the ecosystem has already solved. If you do not want a framework, there is a separate guide for going without one, but the tone is clear: the maintainers think you should not. The bare workflow still exists, but you will be responsible for wiring up navigation and native modules yourself. For a team evaluating adoption, this means the fastest path to a working app is Expo, not the raw `react-native` CLI.

Fast Refresh and the Developer Loop

The README highlights developer velocity as a core feature. JavaScript changes can be applied with Fast Refresh in seconds, without rebuilding the native app. That is a real productivity advantage over pure native development, where a rebuild can take minutes. But the claim comes with a caveat: it applies to JavaScript changes. If you change native code, either in your own native modules or in the React Native core itself, you still need a full rebuild. The README does not quantify the seconds, so treat that as a relative benefit, not a benchmark. The value depends on how often you touch the native layer. For a team using only the standard components, Fast Refresh is a genuine win. For a team writing custom native modules, the loop is closer to traditional native development.

Extending with Native Modules: The Power and the Cost

The README says Native Modules let you call platform code directly from JavaScript, synchronously and type-safe. That is the escape hatch. When the built-in components do not cover a use case, you write Swift or Kotlin and expose it to JavaScript. The documentation on native platform code is separate, but the README points to it. The trade-off is obvious: every native module you write adds maintenance burden and requires a developer who knows the platform language. The README also mentions thousands of existing libraries in the React Native directory, which can save you from writing your own. But third-party libraries vary in quality and maintenance. Before adopting React Native, check that the libraries you need are compatible with the current version and architecture. The README does not promise that every library works out of the box.

Limitations and Failure Modes

The README does not list limitations, but the material implies several. First, the framework is not a silver bullet for UI performance. The README says primitives render to native UI, but it does not claim that every animation or complex gesture will match a hand-written native implementation. Second, the framework's dependency on a JavaScript engine and a bridge means there is an inherent layer of indirection. For CPU-heavy tasks, you may need to write native modules, which brings you back to the platform-specific code you were trying to avoid. Third, the upgrade path is not trivial. The README links to an upgrading guide, which suggests that moving between major versions can be a manual effort. The recent release cadence (three releases in two weeks) means you will be updating often if you want to stay current. Finally, the README's push toward Expo is a constraint: if you choose the bare workflow, you lose the batteries-included experience, and you take on more risk.

Alternatives: Flutter and Native Development

The direct alternative is Flutter, which takes a different approach. Where React Native renders native views, Flutter draws its own UI using a custom rendering engine. That means Flutter apps look identical on Android and iOS, but they do not use the platform's native components. React Native's approach gives you native look and feel, but it means behavior can differ slightly between platforms because the underlying views are different. The trade-off is consistency versus authenticity. The other alternative is writing two native apps, which gives you full control but doubles the cost. The README's own framing, "learn once, write anywhere," is a direct contrast to Flutter's "write once, run anywhere." React Native expects you to reuse your React knowledge, not your UI code verbatim. That is a fundamental difference in philosophy.

Maintenance, Upgrades, and License

React Native is MIT licensed, which means you can use it in commercial projects without paying a fee, and you can modify the source. The repository is actively maintained, with a clear release process discussed in dedicated working groups. The README points to a separate upgrading guide, which implies that upgrades are a documented but ongoing task. The C++ core suggests that the framework is investing in long-term performance, but it also means that contributing to core requires C++ knowledge, not just JavaScript. For most teams, you will not contribute to core; you will consume it. The maintenance cost for you is in keeping your app's dependencies aligned with each new React Native release. The README does not promise automatic migration. Plan for a few days of work per major version upgrade, especially if you use third-party native modules.

Editorial conclusion

Adopt React Native if you have a React team and need cross-platform native UI without maintaining two codebases. Skip it if your app demands pixel-perfect platform-specific interactions or if you cannot tolerate the native toolchain overhead. Before committing, verify your third-party native module list against the current New Architecture compatibility matrix, and test Fast Refresh on your largest component tree. The framework is mature, but the path to production still runs through Xcode and Gradle, not just npm.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes