Flutter gegen React Native: Die Entscheidungen, die erst in der Produktion zutage treten

Flutter und React Native versprechen dasselbe: Einen einzigen Codebase schreiben, ihn für Android und iOS bereitstellen und nicht mehr zwei separate native Apps warten müssen. Auf dem Papier ist das Konzept identisch – und für den ersten Bildschirm einer App stimmt das tatsächlich. Das Erstellen eines Buttons, das Darstellen einer Liste, die Einrichtung der Navigation oder das Anzeigen einer API-Antwort ist in beiden Frameworks unkompliziert. Die Unterschiede, die ein Projekt tatsächlich prägen, zeigen sich dort noch nicht. Sie treten erst auf, wenn die App zu einer benutzerdefinierten Benutzeroberfläche, Animationen, State-Verwaltung, nativen Integrationen sowie jahrelanger Wartung heranwächst. Dies ist ein Vergleich dessen, was nach der Demo unterschiedlich wirkt, damit Sie sich anhand des Verhaltens beider Frameworks in größeren Projekten entscheiden können – und nicht danach, wie schnell sie „Hello World“ darstellen.

Der erste Eindruck ist absichtlich ähnlich

Sowohl Frameworks bieten einen schnellen Weg zu einer laufenden Anwendung. Sie können Benutzeroberflächen erstellen, Navigation hinzufügen, APIs aufrufen, Listen darstellen und Benutzereingaben verarbeiten, ohne in zwei separate native Codebasen aufteilen zu müssen. Genau diese gemeinsame Produktivität ist der Grund, warum Teams zunächst cross-platform-Tools wählen. Eine einfache Benutzeroberfläche sieht unabhängig von der gewählten Plattform fast genauso aus. Erst wenn die Anwendung komplizierter wird, treten die Unterschiede zwischen den beiden Philosophien zutage – daher liegt der echte Vergleich in den komplexen Bereichen und nicht im Starter-Template.

Flutter arbeitet mit Widgets

Der auffälligste Unterschied in Flutter besteht darin, dass fast alles, was man berührt, ein Widget ist. Bildschirme, Schaltflächen, der Abstand um sie herum sowie die Anordnung, die sie strukturiert, sind allesamt Widgets – genauso wie viele Konstrukte, die niemals etwas Sichtbares auf dem Bildschirm zeichnen. Hier stapelt eine Spalte ein Etikett, etwas Abstand und eine Schaltfläche, wobei jedes Element ein eigenes Widget ist, das innerhalb des Baums verschachtelt ist.

Column(
  children: [
    Text('Welcome'),
    SizedBox(height: 16),
    ElevatedButton(
      onPressed: () {},
      child: Text('Continue'),
    ),
  ],
)

Sobald dieses Modell gewählt wird, wird der Aufbau der Benutzeroberfläche erstaunlich konsistent: Man kombiniert kleine Widgets zu größeren, und diese wiederum bilden schließlich ganze Bildschirme. React Native verfolgt einen anderen Ansatz. Es beschreibt die Benutzeroberfläche mit React-Komponenten, die in JavaScript oder TypeScript geschrieben werden, sodass das Denkmuster im Grunde dem Aufbau einer React-App entspricht – was für alle, die bereits mit React arbeiten, sofort verständlich ist. Keines der Modelle ist universell besser. Sie zwingen einen lediglich dazu, über den Aufbau der Benutzeroberfläche in unterschiedlichen Begriffen nachzudenken, wobei das „richtige“ Modell stark davon abhängt, welche Präferenzen das Team bereits hat.

Ausgabe und wie viel Kontrolle man über die Benutzeroberfläche hat

Flutters Renderungsansatz macht es attraktiv für stark angepasste Benutzeroberflächen. Wenn ein Design etwas erfordert, das nicht den Standard-Plattformbildschirmen ähnelt, bietet Flutter ein umfangreiches Widget-Katalog sowie Zeichnungsprimitiven, mit denen man nahezu jedes gewünschte visuelle Ergebnis erstellen kann. Eigene Karten, Animationen, Übergänge, Lader, Diagramme, interaktive Elemente, ungewöhnliche Layouts sowie hochkünstlerisch gestaltete Bildschirme sind alle Teil desselben Widget-Systems.

React Native kann ebenfalls hochgradig anpassbare Benutzeroberflächen erstellen, erreicht dies jedoch auf andere Weise, da es traditionell über seine Laufzeitarchitektur mit den eigenen nativen Komponenten der Plattform arbeitet. Es ist hier wichtig präzise zu sein: Das moderne React Native hat sich mit seiner neuen Architektur erheblich verändert, sodass die alte Beschreibung „JavaScript kommuniziert über eine Brücke mit dem Native-Code“ nicht mehr beschreibt, wie die aktuelle Version tatsächlich funktioniert – Vergleiche, die darauf beruhen, sind daher veraltet. Der eigentliche Punkt ist nicht, dass ein Framework für eine bestimmte Benutzeroberfläche unfähig wäre; beide können sie erstellen. Der Unterschied liegt im Weg, den jedes Framework dafür nimmt, und darin, wie dieser Weg im Alltag wahrgenommen wird.

Dart gegen JavaScript und TypeScript

Ein großer Unterschied zeigt sich bereits bevor man überhaupt eine Benutzeroberfläche entwickelt: die Sprache. Flutter basiert auf Dart; React Native läuft unter JavaScript oder in den meisten ernsthaften Projekten auf TypeScript. Dart ist eine stark typisierte Sprache, die speziell für Flutter entwickelt wurde, und sobald man sich daran gewöhnt hat, erscheint sie als logische Wahl für Anwendungscode. Ein paar typisierte Deklarationen sehen so aus.

final String name = 'Ankit';
final int age = 25;

Diese Art der statischen Typisierung macht größere Codebasen leichter verständlich, denn der Compiler erkennt ganze Kategorien von Fehlern bereits vor dem Ausführen. React Native-Teams greifen häufig auf TypeScript zurück, um im JavaScript-Umfeld denselben Vorteil zu erlangen.

const name: string = 'Ankit';
const age: number = 25;

TypeScript bietet starke Typisierung, bleibt dabei aber Teil des JavaScript-Ökosystems – das ist ein echter Vorteil für Organisationen, die bereits in JavaScript investiert haben. Ein Unternehmen mit einem etablierten React-Entwicklerteam kann React Native oft reibungsloser einführen, da die Entwickler bereits vorhandene Konzepte, Werkzeuge und Gewohnheiten übernehmen können. Für ein Team, das sich stark auf Dart konzentriert, bietet Flutter hingegen eine fokussierte, eigenständige Umgebung. Der Trade‑off besteht dabei aus der Breite eines bestehenden Ökosystems gegenüber der Kohärenz einer speziell dafür konzipierten Umgebung.

State-Management wird nicht mehr trivial

Der Zustand ist der Bereich, in dem die anfängliche Einfachheit am schnellsten verschwindet. Eine kleine Anwendung weist nur wenige Zustandskomponenten auf; eine Produktivanwendung hingegen sammelt eine lange Liste davon an – darunter Authentifizierungsstatus, Benutzerprofildaten, Inhalt des Warenkorbs, Ladezustände von APIs, Paginierung, Suchfilter, Benachrichtigungen, Theme-Einstellungen, lokaler Speicher, Formzustand sowie Echtzeit-Updates. Sobald so viele Aspekte gleichzeitig vorhanden sind, reicht allein das Framework nicht mehr aus. Man benötigt eine Architektur sowie eine bewusste Zustandsstrategie, die darauf aufbaut.

Sowohl Ökosysteme bieten verschiedene Optionen. Auf der Flutter-Seite finden Sie Provider, Riverpod, BLoC, Cubit, GetX und weitere; auf der React Native-Seite gibt es Redux, Zustand, MobX, die Context API sowie viele weitere. Die Anzahl der Pakete sagt hier nur wenig aus. Entscheidend für die Wartbarkeit ist vielmehr, ob Ihr Team in der Lage ist, den Zustand der Anwendung im Laufe der Zeit konsequent zu strukturieren und weiterzuentwickeln. Ein Framework kann zwar hervorragende UI-Leistung liefern, doch wenn die zugrundeliegende Zustandsarchitektur schwach ist, entsteht dennoch eine schwer wartbare Anwendung. Derselbe Ansatz, der dafür sorgt, dass die Architektur einer React-Anwendung kohärent bleibt, gilt auch hier – unabhängig davon, welches Framework die Pixel darstellt.

Leistung ist keine Vergleichszahl

Leistung ist das am häufigsten verwendete Thema in diesem Vergleich. Artikel erklären regelmäßig, ein Framework sei aufgrund eines synthetischen Benchmarks schneller als das andere – doch reale Anwendungen sind keine Benchmarks. Eine Produktionsanwendung kombiniert in der Regel Netzwerkanfragen, große Listen, Bilder, Animationen, Karten, lokalen Speicher, Hintergrundarbeiten, Push-Benachrichtigungen, Webansichten, Analysefunktionen, native SDKs sowie Pakete Dritter – und jeder dieser Bestandteile kann die Leistung beeinflussen.

Eine schlecht entwickelte Flutter-App kann langsam sein, genauso wie eine schlecht entwickelte React Native-App. Unnötige Neubuilds, übermäßiges Rendering, zu große Bilder, ineffiziente Listen, aufwändige Berechnungen, nachlässiger Speicherverbrauch sowie schlecht gestaltete Netzwerkabläufe verursachen Verlangsamungen – unabhängig vom Namen des Frameworks. Die wichtigere Frage ist, wie gut die Architektur der App ihre spezifische Arbeitslast bewältigt, und nicht, welches Framework in einem abstrakten Wettbewerb gewinnt. Die Antwort auf „welches ist schneller“ ist ohne Kenntnis dessen, was man entwickelt, nahezu sinnlos.

Listen machen die Sache konkret

Betrachten wir eine E-Commerce-App mit Tausenden von Produkten. Jedes Produkt in den Speicher zu laden und alle auf einmal anzuzeigen, ist in jedem Framework ein Fehler. Flutter löst dies mit einem Builder, der die Elemente nach Bedarf erstellt, sobald sie ins Sichtfeld scrollen.

ListView.builder(
  itemCount: products.length,
  itemBuilder: (context, index) {
    return ProductCard(
      product: products[index],
    );
  },
)

Das Prinzip besteht darin, nur das zu erstellen, was benötigt wird, anstatt bereits im Voraus alle Elemente zu generieren. React Native bietet denselben Ansatz durch Mechanismen wie FlatList. Auch hier gilt dasselbe Konzept; was sich unterscheidet, sind die spezifischen APIs, das Rendering-Modell, die Optimierungstechniken sowie die damit verbundene Entwicklungserfahrung. Und je komplizierter eine Liste wird, desto wichtiger sind Faktoren wie Paginierung, Bildcaching, Größenanpassung der Elemente, Zustandsaktualisierungen und das Vermeiden unnötiger Neuerstellungen des Renderings – weit mehr als die Wahl des Frameworks.

Das Ökosystem ist der entscheidende Faktor

React Native hat in einer bestimmten Hinsicht einen klaren Vorteil: Es ist Teil des JavaScript-Ökosystems. JavaScript und TypeScript sind bereits überall im Frontend, Backend, in Entwicklungstools sowie im Web verbreitet, und React gehört zu den am weitesten verbreiteten UI-Bibliotheken überhaupt. Organisationen mit starken React-Teams haben daher einen natürlichen Einstieg in React Native, da sie Fähigkeiten und Bibliotheken wiederverwenden können, auf die sie bereits angewiesen sind.

Der Vorteil von Flutter ist vom Gegenteil geprägt. Es bietet ein relativ fokussiertes Ökosystem, das auf Flutter und Dart ausgerichtet ist, was für Teams, die lieber Mobile-Apps entwickeln möchten, ohne sich auf das umfangreiche JavaScript-Umfeld stützen zu müssen, besonders übersichtlich erscheint. Keines der beiden ist strikt besser; die bessere Wahl hängt von dem Team ab, das man bereits hat.

Welches sollte man also wählen?

Es gibt keinen universellen Gewinner – die richtige Entscheidung hängt von den Besonderheiten des Projekts und der beteiligten Personen ab. Wenn ein Team bereits umfangreiche Erfahrung mit React und TypeScript hat, passt React Native nahtlos in seine bestehende Technologiebasis. Wenn ein Team ein speziell für mehrere Plattformen konzipiertes UI-Framework benötigt, das auf Dart und einem widgetbasierten Modell beruht, ist Flutter die logische Wahl. Eine App, die von den vorhandenen React-Kenntnissen des Teams sowie seiner JavaScript-Infrastruktur abhängt, spricht stark für React Native; eine App, die eine hochanpassbare Benutzeroberfläche erfordert und von Personen entwickelt werden soll, die bereits mit Flutter vertraut sind, spricht wiederum stark für das andere Framework. Der Fehler, den man vermeiden sollte, besteht darin, ein Framework auszuwählen, weil ein Artikel es als „besser“ bezeichnet hat, anstatt weil es zum vorliegenden Produkt passt.

Zusammenfassung

Flutter und React Native angehen dasselbe umfassende Problem aus unterschiedlichen Richtungen. Flutter bietet ein widgetbasiertes Modell mit Dart sowie ein eng integriertes UI-Toolkit, das bei kundenspezifischem Design hervorragend funktioniert. React Native bringt das React- und JavaScript-Ecosystem auf mobile Geräte und ermöglicht zugleich den Zugriff auf die Funktionen der nativen Plattform durch eine Architektur, die weit über ihren ursprünglichen Ruf als Brückentechnologie hinaus entwickelt wurde. Keine einzige Wahl macht alle Apps von vornherein besser. Die entscheidende Frage lautet niemals „Welches Framework gewinnt?“, sondern „Welches Framework passt zu diesem Produkt, diesem Team und dieser Art von App?“ Fast alles kann dieses erste Bild anzeigen; erst bei allen folgenden Elementen unterscheiden sich die beiden Frameworks wirklich voneinander.