Teil 3 – Ein Code, zwei Plattformen: Flutter & React Native

Cross-Platform-Entwicklung klingt verlockend. Eine Codebasis, zwei Plattformen, halb so viel Aufwand – so lautet zumindest das Versprechen. Die Realität ist komplizierter, aber keineswegs ernüchternd. Flutter und React Native haben sich in den letzten Jahren als die zwei dominierenden Ansätze herauskristallisiert, und beide verdienen einen ehrlichen Blick – jenseits der Hochglanz-Demos auf den jeweiligen Websites.

Zwei Philosophien, ein Ziel

Der grundlegende Unterschied zwischen Flutter und React Native liegt nicht in der Syntax – er liegt im Denkansatz. React Native setzt auf die nativen UI-Komponenten der jeweiligen Plattform. Eine Schaltfläche auf iOS sieht aus wie eine iOS-Schaltfläche, auf Android wie eine Android-Schaltfläche. Das Framework übersetzt JavaScript-Code zur Laufzeit in plattformeigene Elemente. Flutter geht einen anderen Weg: Es bringt seine eigene Rendering-Engine mit – Skia, inzwischen teilweise Impeller – und zeichnet jedes einzelne Pixel selbst. Die App sieht auf beiden Plattformen identisch aus, weil sie auf beiden Plattformen buchstäblich dasselbe zeichnet.

Keiner dieser Ansätze ist per se besser. Aber sie ziehen sehr unterschiedliche Konsequenzen nach sich, die man verstehen muss, bevor man eine Entscheidung trifft.

Flutter und Dart: Das unerwartete Duo

Googles Cross-Platform-Framework setzt auf Dart – eine Sprache, die vor Flutter kaum jemand auf dem Schirm hatte. Das schreckt anfangs ab. Wer jedoch ein paar Stunden mit Dart verbracht hat, merkt schnell: Die Lernkurve ist flach, die Syntax fühlt sich vertraut an, und das Typsystem ist solide. Dart kompiliert zu nativem ARM-Code, was der Performance spürbar zugute kommt.

Was Flutter wirklich auszeichnet, ist die Konsistenz. Die App sieht auf Android, iOS, Web und Desktop exakt gleich aus – das ist Stärke und Einschränkung zugleich. Wer plattformtypisches Verhalten erwartet, muss es selbst nachbauen oder auf Packages zurückgreifen. Wer dagegen ein einheitliches Erscheinungsbild über alle Plattformen hinweg anstrebt, findet in Flutter ein mächtiges Werkzeug.

Das Ökosystem hat sich in den letzten Jahren enorm entwickelt. pub.dev bietet tausende Packages, die Community ist aktiv, und Google investiert weiterhin stark in das Framework. Besonders für Teams, die von Android-Entwicklung kommen und Kotlin bereits kennen, fühlt sich der Einstieg in Flutter erstaunlich reibungslos an – die Konzepte hinter Widgets und State-Management erinnern an Jetpack Compose.

React Native: JavaScript betritt die Bühne

Meta – damals noch Facebook – veröffentlichte React Native 2015, und seitdem hat das Framework eine turbulente Geschichte hinter sich. Phasen starker Adoption wechselten sich mit Zweifeln an der Architektur ab, bis die sogenannte „New Architecture“ mit JSI und Fabric das Fundament grundlegend erneuerte. Wer React Native vor drei oder vier Jahren abgeschrieben hat, sollte noch einmal hinschauen.

Der größte Vorteil von React Native liegt auf der Hand: JavaScript. Die Sprache kennt fast jeder Webentwickler, das React-Paradigma ist weit verbreitet, und der Einstieg fällt vielen Teams leicht. TypeScript lässt sich problemlos integrieren und bringt die nötige Typsicherheit mit. Wer bereits eine React-Webanwendung betreibt, kann Logik und Kenntnisse direkt wiederverwenden – das ist in der Praxis ein handfester Vorteil.

Die neue Architektur hat die lange kritisierte JavaScript-Bridge abgelöst. Statt asynchroner Kommunikation zwischen JS-Thread und nativem Layer gibt es jetzt synchronen Zugriff über JSI – das macht einen messbaren Unterschied bei animationsintensiven oder rechenaufwändigen Anwendungen. Trotzdem: React Native bleibt abhängig von nativen Modulen für plattformspezifische Features, und deren Qualität variiert je nach Package erheblich.

Dart vs. JavaScript: Was zählt wirklich?

Rein technisch betrachtet hat Dart die Nase vorn. Die Sprache wurde für Flutter entworfen, compiliert zu nativem Code, und bietet ein konsistentes Entwicklungserlebnis ohne die Eigenheiten von JavaScript. Aber Technologie entscheidet selten allein. JavaScript bringt ein gigantisches Ökosystem mit, eine riesige Entwicklergemeinschaft, und – das sollte man nicht unterschätzen – jahrelange Erfahrung in vielen Teams.

Die ehrliche Einschätzung: Wer von null anfängt und keine bestehende JavaScript-Codebasis mitbringt, greift vermutlich zu Flutter. Wer ein Web-Team hat, das React kennt, fährt mit React Native besser. Die Sprache ist fast immer das kleinste Problem – die Architekturentscheidung dahinter ist die eigentlich wichtige.

Praxistauglichkeit: Was bleibt nach dem Demo-Projekt?

Beide Frameworks haben längst bewiesen, dass sie produktionsreif sind. Flutter steckt in den Apps von BMW, eBay und Alibaba. React Native treibt Teile von Facebook, Instagram und Shopify an. Das Argument „zu riskant für echte Projekte“ zieht nicht mehr.

Was in der Praxis jedoch zählt: Wie verhält sich das Framework, wenn plattformspezifische Features gefragt sind? Wie schnell reagiert die Community auf neue Betriebssystem-Versionen? Wie aufwändig ist das Debugging, wenn es tief ins System geht? Bei Flutter ist das eigene Rendering-Modell dort eine Herausforderung, wo native UI-Verhalten erwartet wird – Barrierefreiheit zum Beispiel war lange eine Schwachstelle, hat sich aber verbessert. Bei React Native ist die Abhängigkeit von Drittanbieter-Packages ein Risiko, das man im Blick behalten muss.

Fazit für Teil 3

Flutter und React Native sind keine Kompromisslösungen mehr – sie sind vollwertige Werkzeuge mit klaren Stärken und klar definierten Grenzen. Flutter überzeugt durch Konsistenz, Performance und ein durchdachtes Entwicklungserlebnis. React Native punktet mit einem riesigen Ökosystem, der Verbreitung von JavaScript und der nahtlosen Verzahnung mit bestehenden Web-Teams. Wer sich zwischen beiden entscheiden muss, sollte nicht auf Benchmarks schauen – sondern auf sein Team, seine Anforderungen und seine bestehende Infrastruktur.

Und wer glaubt, mit einer dieser Optionen alle Probleme zu lösen: Teil 4 wartet noch.