React Native

In short: A framework for writing native iOS and Android apps with React/JavaScript instead of Swift/Kotlin — one codebase for both platforms.

In more detail: Unlike a webview app, React Native renders real native UI elements (no embedded browser), by having JavaScript code communicate with the native platform at runtime. This lets a lot of code be shared between iOS and Android, while platform-specific customisation remains possible.

In Depth

The bridge to native components

The decisive technical difference from a “hybrid app” (which is essentially a website shown in an embedded browser window, as with apps built with Cordova/Ionic) is that React Native code communicates with the platform’s actual native UI components via a so-called “bridge” — a React Native <Text> element is mapped at runtime to a real UILabel (iOS) or TextView (Android), not rendered as HTML and displayed in a browser context. The result feels like a “real” native app to users — native scroll physics, native animations, native accessibility support — while most of the application logic and UI structure exists as shared JavaScript code between iOS and Android.

import { View, Text, Button } from "react-native";
 
function App() {
  return (
    <View>
      <Text>Welcome back!</Text>
      <Button title="Order" onPress={() => console.log("Click!")} />
    </View>
  );
}

Limits of code reuse

In practice, platform-specific code remains necessary as soon as you dig deep into operating-system features: certain sensors with platform-specific behaviour, push-notification nuances (iOS and Android have different push systems), or app-store-specific requirements (e.g. different in-app purchase APIs between Apple and Google). React Native considerably reduces duplication effort compared to completely separate native development — often 70-90% of the code is shared — but doesn’t eliminate it entirely.

Competing approaches

Competing approaches like Flutter (from Google, with its own rendering engine instead of mapping to native components — Flutter draws its UI elements entirely itself, instead of using native UILabel/TextView equivalents) pursue a similar basic idea (one codebase, several platforms), but with a different technical trade-off: Flutter apps look identical on all platforms (since they’re self-drawn), while React Native apps tend to adopt more of the respective native platform look-and-feel. Which approach is “better” depends heavily on the project — companies with existing React/JavaScript know-how tend towards React Native, teams without existing JavaScript expertise more often choose Flutter.

See also: React, Android, iOS