React Native: One Codebase for iOS and Android

To understand why React Native performs so well today, it helps to look at its original architecture. JavaScript code has always run on its own thread, separate from the native UI thread on iOS and Android. For the two sides to talk to each other, there was the so-called "Bridge": messages were serialized as JSON, batched into packets, and sent asynchronously back and forth between threads. Picture two people who can only communicate through handwritten notes carried by a messenger. It works reliably, but it costs time, especially when many small messages need to be sent in quick succession, for example during animations tied to scrolling or swipe gestures.

That exact bottleneck is what the so-called "New Architecture" removed, and it is now the default in every new React Native project. Its core is the JavaScript Interface (JSI), a thin C++ layer that lets JavaScript and native code call each other directly and, when needed, synchronously, with no detour through serialization and messengers. In the picture from before: the two people are now sitting in the same room, talking directly to each other.

Two further building blocks sit on top of the JSI: Fabric, the new rendering system that creates and updates native UI components more directly and works cleanly with modern React concepts such as concurrent rendering, and TurboModules, which load native modules only when an app actually needs them instead of loading everything upfront at startup. Combined with the Hermes JavaScript engine, which is optimized for mobile devices and precompiles code to bytecode ahead of time, the result is startup and runtime behavior that now comes very close to a fully native app.

Three properties explain why React Native has remained one of the leading cross-platform technologies for a decade.

A decade after its first release, the reach of React Native can be measured through concrete figures and well-known real-world use cases.

For an honest reading: not every app listed above uses React Native for 100 percent of its interface. Many larger companies deliberately choose a hybrid approach, keeping select, particularly performance-critical screens native while running the bulk of the app on React Native.

Google's Flutter takes a different technical approach: rather than using native UI components, Flutter draws every interface itself with its own rendering engine (Impeller, formerly Skia). The result is a pixel-identical look across every platform, but it requires the team to learn Dart from scratch. React Native, by contrast, adapts to native platform conventions, which can be an advantage or a drawback depending on the project.

Fully native development with Swift/SwiftUI on iOS and Kotlin/Jetpack Compose on Android remains the reference point for maximum performance and the most immediate access to new operating system features, but it requires two separate teams and two parallel development cycles. The table below summarizes the key differences.

Assessment based on the statements in this chapter, reflecting the state of these technologies at the time of publication.

In practice, the decision rarely comes down to technical criteria alone. Teams that already have a React web team and need to reach two stores quickly are usually best served by React Native. Teams that want a distinctive, brand-defining visual design reproduced pixel-for-pixel across many platforms often find Flutter the better answer. And teams building an app that must use every new operating system feature with zero delay from day one, for example around wearables or highly specific hardware integrations, rarely get around fully native development. All three paths lead to a working app; they mainly differ in budget, team structure and time horizon.