Jeder Cross-Platform-Vergleich, den Sie je gelesen haben, beginnt mit der Beteuerung, es gebe keine falsche Antwort. Das ist die höfliche Art, der Frage auszuweichen. Es gibt falsche Antworten — sie hängen nur davon ab, was Sie bauen und wer es baut.
Hier also die Fassung mit Meinung drin.
Die drei lösen nicht dasselbe Problem
Diesen Teil überspringen die meisten Vergleiche, und er erklärt fast jede Meinungsverschiedenheit über sie.
Flutter rendert seine Oberfläche selbst. Es liefert eine eigene Rendering-Engine mit, zeichnet jeden Pixel selbst und benutzt die nativen Widgets der Plattform gar nicht. Ein Flutter-Button ist auf beiden Plattformen ein Flutter-Button — deshalb sieht eine Flutter-App überall identisch aus, und deshalb kann sie sich auf beiden subtil fremd anfühlen.
React Native macht das Gegenteil. Es steuert echte native Komponenten — einen echten UIButton auf iOS, einen echten Android-Button — aus JavaScript heraus. Plattformnatives Aussehen und Verhalten gibt es gratis, dafür erbt man die Komplexität einer Brücke zwischen zwei Laufzeitumgebungen.
Kotlin Multiplatform teilt keins von beidem. Es teilt Ihre Geschäftslogik — Netzwerk, Datenmodelle, Validierung, Speicherung — und lässt die gesamte Oberfläche auf jeder Plattform nativ. Sie schreiben SwiftUI auf iOS und Jetpack Compose auf Android, und beide rufen in einen gemeinsamen Kotlin-Kern.
Eines davon ist nicht wie die anderen. Flutter und React Native versuchen, die App einmal zu schreiben. KMP versucht das ausdrücklich nicht.
Abb. — Drei verschiedene Antworten auf die Frage, was «geteilt» heissen soll.
Flutter: das, was am schnellsten liefert
Wenn Ihre Priorität ist, schnell eine polierte, konsistente App in beide Stores zu bringen, ist Flutter immer noch die stärkste Antwort — und zwar deutlich.
Der Grund: Wer die Rendering-Schicht besitzt, eliminiert eine ganze Problemkategorie. Ihr Layout verhält sich auf beiden Plattformen identisch, weil derselbe Code dieselben Pixel zeichnet. Sie jagen keinem Bug hinterher, der nur bei der Schriftskalierung eines einzelnen Android-Herstellers auftritt. Hot Reload funktioniert wirklich. Die Widget-Bibliothek ist umfassend genug, dass die meisten Screens gar keinen plattformspezifischen Code brauchen.
Die Kosten sind trotzdem real. Die App-Grösse startet höher, weil Sie eine Engine mitliefern. Tiefe Plattform-Integration — eine komplexe Kamera-Pipeline, ein Bluetooth-Gerät, alles Ungewöhnliche — heisst Platform Channels schreiben: nativer Code mit Zusatzschritten und einer Grenze, über die hinweg man debuggt. Und wenn das OS ein neues natives Control ausliefert, implementiert Flutter es nach eigenem Zeitplan nach, statt es zu erben.
Auch die Barrierefreiheit verdient eine Erwähnung. Weil Flutter zeichnet statt native Views zu komponieren, hängt die Screenreader-Unterstützung daran, dass Flutters Semantik-Schicht korrekt beschreibt, was gemalt wurde. Das ist inzwischen ordentlich. Es bleibt eine Übersetzung — und Übersetzungen verlieren etwas.
Wählen Sie Flutter für Consumer-Apps mit eigenem Designsystem, inhaltslastige Produkte und alles, wo ein unverwechselbarer Marken-Look mehr zählt als Plattformkonvention.
React Native: das, was zum vorhandenen Team passt
Das stärkste Argument für React Native war nie technisch. Es lautet: Sie beschäftigen vermutlich bereits React-Entwickler, und die sind darin binnen einer Woche produktiv.
Unterschätzen Sie das nicht. Ein Team aus vier Web-Engineers, das ohne Neueinstellung eine kompetente Mobile-App ausliefert, ist ein materiell anderes Angebot, als Swift- und Kotlin-Spezialisten in einem Markt zu rekrutieren, in dem beide teuer sind.
Auch das technische Bild hat sich stärker verbessert, als sein Ruf vermuten lässt. Die neue Architektur hat die asynchrone Brücke entfernt, die die meisten historischen Performance-Klagen verursachte, und der Abstand zwischen einer gut gebauten React-Native-App und einer nativen ist für die grosse Mehrheit der Apps für Nutzer unsichtbar geworden.
Wo es weiter weh tut: das Dependency-Management. Ein React-Native-Projekt mit ein paar Jahren auf dem Buckel sammelt native Module verschiedener Maintainer mit verschiedenen Upgrade-Zyklen, und ein Major-Versionssprung kann zu einer Woche Entwirren werden. Diese Wartungssteuer ist der ehrliche Nachteil — und sie ist laufend, nicht einmalig.
Wählen Sie React Native, wenn Ihr Team ohnehin JavaScript-lastig ist, wenn Sie echtes plattformnatives Gefühl ohne zwei Oberflächen wollen, oder wenn Sie Logik mit einer bestehenden Web-App teilen müssen.
Kotlin Multiplatform: das, was zugibt, dass die Oberfläche der harte Teil ist
KMP ist das interessanteste der drei, weil es die Prämisse verweigert. Es versucht nicht, Ihre Oberfläche einmal zu schreiben. Es geht davon aus, dass Sie beide Oberflächen nativ bauen — und teilt nur die Schicht darunter.
Das klingt nach mehr Arbeit, und anfangs ist es das. Was Sie dafür bekommen: Die härtesten 40% Ihrer App — Netzwerk, Offline-Sync, Datenmodelle, Geschäftsregeln, Validierungslogik — existieren einmal, in einer Sprache, einmal getestet. Derweil ist jede Plattform-Oberfläche vollständig nativ, nutzt die aktuellen OS-Controls am Tag ihres Erscheinens und verhält sich exakt so, wie Nutzer dieser Plattform es erwarten.
Für ein Team, das bereits iOS- und Android-Entwickler hat, ist das oft das qualitativ beste erreichbare Ergebnis. Niemand muss ein neues UI-Framework lernen. Die Apps fühlen sich richtig an. Die duplizierte Logik, die früher zwischen den Plattformen auseinanderdriftete, driftet nicht mehr.
Die Vorbehalte sind ehrliche. Sie brauchen weiterhin beide Skill-Sets — es spart also weniger Personal als die anderen. Das Tooling rund um die iOS-Integration ist deutlich besser geworden, bleibt aber rauer als auf Android. Und das Ökosystem ist kleiner, Sie schreiben also mehr selbst.
Wählen Sie KMP, wenn Sie bereits native Entwickler haben, wenn die Korrektheit geteilter Logik mehr zählt als Liefertempo, oder wenn die App Jahre leben wird und Sie auf Wartung optimieren statt auf den Launch.
Und die Performance, wirklich
Performance ist das Argument, nach dem Leute greifen, wenn sie einen technischen Grund für eine bereits gefasste Vorliebe suchen. Also lohnt sich Präzision, wo sie zählt und wo nicht.
Für die überwältigende Mehrheit der Apps — Formulare, Listen, Inhalte, Checkout, Chat — sind alle drei schnell genug, dass Nutzer keinen Unterschied merken. Der Engpass einer typischen App ist das Netzwerk, nicht die Rendering-Schicht. Über Frame-Zeiten zu streiten, während Ihre API 900 Millisekunden für eine Produktliste braucht, heisst das Falsche optimieren.
Wo die Unterschiede sichtbar werden: lange Scroll-Listen mit komplexen Zellen, animationslastige Oberflächen bei 120 Hz, Echtzeit-Bild- oder Videoverarbeitung, und Apps, die auf billiger Android-Hardware sofort starten müssen. Bei den ersten drei haben Flutter und KMP einen Vorteil. Bei Kaltstart und App-Grösse gewinnen Nativ und KMP — und Flutters Engine ist ein echtes Handicap auf günstigen Geräten in Märkten, wo Speicher knapp ist.
Der nützliche Test ist kein Benchmark. Bauen Sie Ihren einzelnen komplexesten Screen im Framework Ihrer Wahl, lassen Sie ihn auf dem schlechtesten Telefon laufen, das Ihre Nutzer tatsächlich besitzen, und spüren Sie nach. Das dauert zwei Tage und entscheidet den Streit besser als jede Vergleichstabelle.
Die Kosten, die in keiner Schätzung stehen
Beim Einstellen entscheidet sich, ob die Cross-Platform-Rechnung aufgeht oder leise scheitert.
Flutter-Entwickler sind zahlreich und günstiger als native Spezialisten, aber der Pool ist bei tiefer Expertise flacher — viele können Screens bauen, wenige einen Platform Channel debuggen oder ein Ruckel-Problem in der Engine profilieren. React Native erbt den enormen React-Talentpool, sein grösster praktischer Vorteil — wobei «kennt React» und «hat eine React-Native-App durch drei OS-Releases gebracht und gepflegt» verschiedene Dinge sind und verschieden bepreist werden.
KMP ist am schwersten zu besetzen, denn Sie stellen keine KMP-Entwickler ein. Sie stellen iOS- und Android-Entwickler ein, die bereit sind, in geteiltem Kotlin zu arbeiten — und die zweite Hälfte dieses Satzes eliminiert mehr Kandidaten, als Sie erwarten würden.
Rechnen Sie auch die Ersatzkosten ein. Wenn eine Person geht: Wie lange, bis jemand anderes den Code gefahrlos ändern kann? Diese Frage begünstigt die langweilige Wahl öfter, als Teams beim Wählen zugeben.
Die Entscheidung, ohne Ausflüchte
Sie haben kein Mobile-Team und müssen dieses Quartal liefern: Nehmen Sie Flutter. Liefertempo und Konsistenz dominieren in dieser Phase alles andere, und neu schreiben können Sie später, falls das Produkt überlebt.
Sie haben ein React-Team und keine Mobile-Einstellungen geplant: Nehmen Sie React Native. Die Team-Passung wiegt die Wartungssteuer auf, und der Performance-Einwand trägt für die meisten Produkte nicht mehr.
Sie haben bereits iOS- und Android-Engineers: Nehmen Sie Kotlin Multiplatform. Personal sparen Sie ohnehin nicht — investieren Sie den geteilten Code dort, wo er sich wirklich auszahlt: in die Logik, nicht in die Buttons.
Es gibt eine vierte Option, die laut gesagt gehört: Wenn Sie eine App für eine Plattform bauen, weil Ihre Nutzer tatsächlich dort sind — bauen Sie nativ und hören Sie auf, Vergleichsartikel zu lesen. Cross-Platform ist die Lösung für das Problem, zwei Plattformen zu bedienen. Haben Sie dieses Problem nicht, zahlen Sie eine Steuer für nichts: eine Abstraktionsschicht extra, ein Upgrade-Laufband extra und ein langsamerer Weg zu jedem neuen OS-Feature. Genug Teams wählen Flutter für eine App, die nur je auf Android erscheint.
Und wenn Ihre App wirklich einfach ist, schliesst eine gut gebaute mobile Web-App die Lücke womöglich ganz. Das ist nicht die modische Antwort — aber etliche Apps in den Stores wären als Website mit ordentlichem Install-Prompt besser dran gewesen.
Ein Vorbehalt zu alledem: Diese Entscheidung lässt sich revidieren, und Teams behandeln sie, als wäre sie endgültig. Eine zwei Jahre alte App in einem anderen Framework neu zu schreiben ist teuer, aber überlebbar — und ein kleineres Projekt, als die meisten annehmen, denn das hart Erarbeitete — die API-Verträge, die Geschäftsregeln, das Wissen, was Nutzer wirklich tun — trägt sich unverändert hinüber. Was sich nicht hinüberträgt, ist die UI-Schicht, und die war meistens ohnehin der Teil, der die Neuschreibung brauchte. Falsch wählen ist verkraftbar. Vier Monate mit Wählen verbringen nicht.
Die Framework-Wahl zählt weniger, als Teams erwarten — und das Team, das Sie haben, zählt weit mehr, als sie zugeben wollen. Ein fähiges Team liefert eine gute App im falschen Framework. Ein strauchelndes Team liefert eine schlechte im richtigen, pünktlich, und niemand versteht, warum sie sich billig anfühlt.
Den richtigen Stack für ein bestimmtes Team und Produkt zu wählen ist die Art Arbeit, die wir bei CODT machen.
