The promise of cross-platform mobile development โ write once, deploy to iOS and Android โ has been chased since smartphones became ubiquitous. React Native, now in version 0.73 with the New Architecture enabled by default, delivers on this promise in a way that earlier cross-platform solutions did not. Understanding its genuine capabilities and its remaining limitations helps teams make a more informed build-vs-native decision.
How React Native Works Under the Hood
React Native does not compile JavaScript to native code. Instead, it runs JavaScript on a dedicated thread and communicates with a native UI thread through a bridge (and now, with the New Architecture, through JSI โ JavaScript Interface โ which provides synchronous access to native modules). Components render as genuine native views: a React Native Text component renders as UITextView on iOS and TextView on Android, not as an HTML element in a WebView.
This is the fundamental distinction between React Native and hybrid approaches like Ionic or Cordova, which render HTML in a WebView. React Native applications look, feel, and perform like native applications because they use native UI components โ the JavaScript layer handles logic and coordination, not rendering.
The Business Case: When React Native Wins
The cost argument for React Native over separate iOS and Android native codebases is straightforward: one codebase, one team, one set of business logic, one deployment pipeline. For business applications โ internal tools, customer portals, field service apps, logistics applications โ where the primary requirements are UI composition, data display, form handling, and API integration, React Native provides this in a shared codebase that typically shares 85โ95% of code between platforms.
Time to market is the other compelling factor. Shipping a React Native MVP for both platforms simultaneously takes significantly less time than building and maintaining two separate native codebases. For applications that need to validate a concept or reach both platforms quickly, this is often the deciding factor.
Where Native Development Remains Superior
Native development โ Swift/SwiftUI for iOS, Kotlin/Jetpack Compose for Android โ remains the better choice for applications with heavy platform-specific requirements: applications that need deep system integration (e.g. CoreBluetooth on iOS, complex gesture recognisers, platform-specific notification handling), applications that push hardware capabilities (camera processing, AR, high-frame-rate animations), and applications where native performance and the full platform API surface are commercial requirements.
Games, media-heavy creative tools, and applications with complex platform-specific UX (extensive use of native navigation paradigms, deep system integration) are better served by native development. The overhead of bridging to native modules for complex platform features is manageable for occasional use cases but becomes burdensome for applications that depend on them centrally.
Expo: The Right Starting Point for Most Projects
Expo provides a managed workflow on top of React Native that handles build configuration, native dependency management, and over-the-air (OTA) updates for JavaScript bundles. For most business applications, Expo’s managed workflow provides a faster, less infrastructure-heavy path to a production app than bare React Native. The cases where you need to eject from Expo’s managed workflow to bare React Native are genuine but narrower than commonly assumed โ typically when you need a native module that has no Expo equivalent.