React Native

Kurz: Ein Framework, mit dem man native iOS- und Android-Apps mit React/JavaScript statt Swift/Kotlin schreibt — ein Codebase für beide Plattformen.

Genauer: Anders als eine Webview-App rendert React Native echte native UI-Elemente (kein eingebetteter Browser), indem JavaScript-Code zur Laufzeit mit der nativen Plattform kommuniziert. Dadurch lässt sich viel Code zwischen iOS und Android teilen, plattformspezifische Anpassungen bleiben aber trotzdem möglich.

Im Detail

Die Bridge zu nativen Komponenten

Der entscheidende technische Unterschied zu einer “Hybrid-App” (die im Kern eine Website in einem eingebetteten Browser-Fenster zeigt, wie z. B. mit Cordova/Ionic gebaute Apps) ist, dass React-Native-Code über eine sogenannte “Bridge” mit den tatsächlichen nativen UI-Komponenten der Plattform kommuniziert — ein React-Native-<Text>-Element wird zur Laufzeit auf ein echtes UILabel (iOS) bzw. TextView (Android) abgebildet, nicht in HTML gerendert und im Browser-Kontext dargestellt. Das Ergebnis fühlt sich für Nutzer wie eine “echte” native App an — native Scroll-Physik, native Animationen, native Barrierefreiheit-Unterstützung —, während der Großteil der Anwendungslogik und UI-Struktur als geteilter JavaScript-Code zwischen iOS und Android existiert.

import { View, Text, Button } from "react-native";
 
function App() {
  return (
    <View>
      <Text>Willkommen zurück!</Text>
      <Button title="Bestellen" onPress={() => console.log("Klick!")} />
    </View>
  );
}

Grenzen der Code-Wiederverwendung

In der Praxis bleibt trotzdem plattformspezifischer Code nötig, sobald tief in Betriebssystem-Funktionen eingegriffen wird: bestimmte Sensoren mit plattformspezifischem Verhalten, Push-Benachrichtigungs-Feinheiten (iOS und Android haben unterschiedliche Push-Systeme), oder App-Store-spezifische Anforderungen (z. B. unterschiedliche In-App-Kauf-APIs zwischen Apple und Google). React Native reduziert den Duplizierungsaufwand gegenüber komplett getrennter nativer Entwicklung erheblich — oft werden 70-90% des Codes geteilt —, eliminiert ihn aber nicht vollständig.

Konkurrierende Ansätze

Konkurrenzansätze wie Flutter (von Google, eigene Rendering-Engine statt Abbildung auf native Komponenten — Flutter zeichnet seine UI-Elemente komplett selbst, statt native UILabel/TextView-Äquivalente zu nutzen) verfolgen eine ähnliche Grundidee (ein Codebase, mehrere Plattformen), aber mit einem anderen technischen Kompromiss: Flutter-Apps sehen auf allen Plattformen identisch aus (da selbst gezeichnet), React-Native-Apps übernehmen tendenziell mehr vom jeweiligen nativen Plattform-Look-and-Feel. Welcher Ansatz “besser” ist, hängt stark vom Projekt ab — Unternehmen mit vorhandenem React/JavaScript-Know-how tendieren zu React Native, Teams ohne bestehende JavaScript-Expertise wählen häufiger Flutter.

Siehe auch: React, Android, iOS