Jeder Vergleich Flutter vs. React Native vs. Kotlin Multiplatform, den Sie je gelesen haben, beginnt mit der Beteuerung, es gebe keine falsche Antwort. Ich finde, damit weicht man der Frage aus. Manche Wahl ist für eine bestimmte App falsch, und welche, hängt davon ab, was Sie bauen und wer es baut.
Hier also die Fassung mit Meinung drin.
Flutter vs. React Native vs. Kotlin Multiplatform: die kurze Antwort
Kurz gesagt: Ohne Mobile-Team und mit Launch in diesem Quartal nehmen Sie Flutter. Beschäftigen Sie schon React-Entwickler, React Native. Haben Sie iOS- und Android-Entwickler im Haus, Kotlin Multiplatform: ein gemeinsamer Kern, zwei native Oberflächen. Und wenn Sie nur eine Plattform brauchen, bauen Sie nativ und lassen alle drei weg.
| Flutter | React Native | Kotlin Multiplatform | |
|---|---|---|---|
| Was geteilt wird | Oberfläche und Logik, gezeichnet von der eigenen Engine | Oberfläche und Logik, angezeigt als echte native Komponenten | Die Logik; die Oberfläche nur mit Compose Multiplatform |
| Sprache | Dart | JavaScript oder TypeScript | Kotlin, dazu Swift für eine native iOS-Oberfläche |
| Passt am besten | Noch kein Mobile-Team, Launch bald, starker Marken-Look | Ein React-Team, das Sie schon beschäftigen | iOS- und Android-Entwickler, die Sie schon beschäftigen |
| Wo es später wehtut | Grössere App, zusätzlicher nativer Code für tiefe Hardware-Anbindung | Upgrades nativer Module von vielen verschiedenen Maintainern | Sie brauchen weiter beide Skill-Sets, das Ökosystem ist kleiner |
| Rekrutierung | Grosser Pool, wenige echte Spezialisten | Der grösste Pool, über React | Am schwersten: native Entwickler, die in geteiltem Kotlin arbeiten wollen |
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 leicht 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 bekommen Sie die Komplexität von zwei Laufzeitumgebungen, die miteinander reden müssen.
Kotlin Multiplatform teilt im Standardfall nur 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 greifen auf einen gemeinsamen Kotlin-Kern zu.
Abb. — Drei verschiedene Antworten auf die Frage, was «geteilt» heissen soll.
Hinter jedem Framework steckt eine Sprache: Dart bei Flutter, JavaScript oder TypeScript bei React Native, Kotlin bei KMP. Falls Sie die Sprache noch nicht festgelegt haben, geht unser englischsprachiger Überblick über App-Programmiersprachen sie einzeln durch.
Flutter: am schnellsten in den Stores
Wenn Ihre Priorität ist, schnell eine polierte, einheitliche App in beide Stores zu bringen, ist Flutter immer noch die stärkste Antwort, und zwar deutlich.
Der Grund: Wer die Rendering-Schicht selbst besitzt, ist eine ganze Sorte Probleme los. 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. 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 Betriebssystem ein neues natives Control ausliefert, muss Flutter es nachbauen, nach eigenem Zeitplan.
Auch die Barrierefreiheit verdient eine Erwähnung. Weil Flutter zeichnet, statt native Views zusammenzusetzen, hängt die Screenreader-Unterstützung daran, dass Flutters Semantik-Schicht korrekt beschreibt, was gezeichnet 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, bei dem ein unverwechselbarer Marken-Look mehr zählt als Plattformkonvention.
React Native: passt zum Team, das Sie schon haben
Das stärkste Argument für React Native ist das Team: 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 solide Mobile-App ausliefert, ist etwas ganz anderes, als Swift- und Kotlin-Spezialisten in einem Markt zu suchen, 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 alten Performance-Klagen verursachte, und seit React Native 0.82 (Oktober 2025) laufen Apps nur noch auf dieser Architektur. 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 wehtut: 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. Dieser Wartungsaufwand ist der eigentliche Nachteil, und er hört nie auf.
Wählen Sie React Native, wenn Ihr Team ohnehin JavaScript-lastig ist oder wenn Sie Logik mit einer bestehenden Web-App teilen müssen.
Kotlin Multiplatform: gibt zu, dass die Oberfläche der schwierige Teil ist
KMP ist das interessanteste der drei, weil es die übliche Grundannahme nicht mitmacht. 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: Der schwierige Teil unter den Screens (Netzwerk, Offline-Sync, Datenmodelle, Geschäftsregeln, Validierungslogik) existiert einmal, in einer Sprache, einmal getestet. Derweil ist jede Plattform-Oberfläche vollständig nativ, nutzt die aktuellen Controls des Betriebssystems am Tag ihres Erscheinens und verhält sich genau 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 doppelte Logik, die früher zwischen den Plattformen auseinanderlief, läuft nicht mehr auseinander.
Es gibt Haken. 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.
Eines hat sich seit den Anfängen von KMP geändert. JetBrains hat Compose Multiplatform für iOS im Mai 2025 für stabil erklärt (Version 1.8.0). Sie können also inzwischen auch die Oberfläche teilen, einmal in Compose geschrieben. Das ist eine echte Option. Aber wer alles teilt, ist wieder auf Flutters Terrain, und dann würde ich die beiden an Ihrem schwierigsten Screen vergleichen, bevor Sie entscheiden. Wenn natives Gefühl der Grund für KMP war, bleiben Sie auf iOS bei SwiftUI.
Es passt zu einer App, die viele Jahre laufen soll und bei der die Wartung mehr zählt als der Launch-Tag.
Und was ist mit der Performance?
Performance ist das Argument, nach dem Leute greifen, wenn sie einen technischen Grund für eine bereits gefasste Vorliebe suchen. Darum lohnt es sich, genau hinzuschauen, wo sie zählt und wo nicht.
Nehmen Sie Formulare, Listen, Inhalte, Checkout und Chat: Für die überwältigende Mehrheit der Apps sind alle drei schnell genug, dass Nutzer keinen Unterschied merken. In einer typischen App bremst das Netzwerk. Ü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 Handicap auf günstigen Geräten in Märkten, wo Speicher knapp ist.
Der Test, dem ich aus Sicht der Qualitätssicherung vertraue, ist simpel. Bauen Sie Ihren komplexesten Screen im Framework Ihrer Wahl, lassen Sie ihn auf dem schlechtesten Telefon laufen, das Ihre Nutzer tatsächlich besitzen, und schauen Sie, wie er sich anfühlt. Das dauert ein paar Tage und entscheidet den Streit besser als jede Vergleichstabelle, auch die oben auf dieser Seite.
Die Kosten, die in keiner Schätzung stehen
Beim Einstellen entscheidet sich, ob die Cross-Platform-Rechnung aufgeht oder leise scheitert.
Flutter-Entwickler sind leichter zu finden 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 aufspüren. React Native erbt den riesigen React-Talentpool, sein grösster praktischer Vorteil. Nur sind «kennt React» und «hat eine React-Native-App durch drei OS-Releases gebracht und gepflegt» zwei verschiedene Dinge, und sie kosten verschieden viel.
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 siebt mehr Kandidaten aus, 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 spricht öfter für die langweilige Wahl, als Teams beim Wählen zugeben. (Wenn Sie zwischen einem einzelnen Freelancer und einer Agentur für den Bau abwägen, behandelt dieser Leitfaden diese Seite der Frage.)
Was wir bei eigenen Projekten gewählt haben
Zwei Apps aus unserem Portfolio, zwei verschiedene Antworten. Die Apps zum FeelEat Happy Fridge, die den Kühlschrank öffnen und das Menü zeigen, starteten als native WebView-Hüllen und wurden ab 2023 in Flutter neu gebaut. Bei FeelEats App für die Mitarbeitenden sind wir den anderen Weg gegangen: getrennte native Apps für iOS und Android, damit jedes Betriebssystem die volle Performance und die Anmeldung per Gesicht oder Fingerabdruck bekommt. Das war im Bau teurer, dafür ist der Betrieb risikoärmer.
Keines unserer veröffentlichten Projekte nutzt bisher Kotlin Multiplatform. Der KMP-Teil oben stützt sich also auf öffentliche Dokumentation und das Ökosystem; eine eigene KMP-Veröffentlichung haben wir noch nicht.
Die Entscheidung, ohne Ausflüchte
Sie haben kein Mobile-Team und müssen dieses Quartal liefern: Nehmen Sie Flutter. Liefertempo und Einheitlichkeit schlagen 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. Dass das Team schon passt, wiegt den Wartungsaufwand 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, also setzen Sie den geteilten Code dort ein, wo er sich wirklich auszahlt: in der Logik, nicht bei den Buttons.
Es gibt eine vierte Option, die man laut aussprechen sollte: 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 für nichts drauf: eine zusätzliche Abstraktionsschicht, zusätzliche Updates, die Sie ständig nachziehen müssen, und einen langsameren Weg zu jedem neuen Feature des Betriebssystems. Flutter für eine App zu wählen, die es immer nur für Android geben wird, ist genau dieses Draufzahlen.
Und wenn Ihre App wirklich einfach ist, schliesst eine gut gebaute mobile Web-App die Lücke womöglich ganz. Das ist eine unmodische Antwort. Trotzdem wären etliche Apps in den Stores als Website mit ordentlichem Install-Hinweis besser dran gewesen.
Ein Vorbehalt zu alledem: Diese Entscheidung lässt sich revidieren, auch wenn man sie leicht wie eine endgültige behandelt. Eine zwei Jahre alte App in einem anderen Framework neu zu schreiben ist teuer, aber überlebbar. Es ist auch ein kleineres Projekt, als die meisten annehmen, denn das hart Erarbeitete (die API-Verträge, die Geschäftsregeln, das Wissen, was Nutzer wirklich tun) kommt unverändert mit. Was nicht mitkommt, ist die UI-Schicht, und die war meistens ohnehin der Teil, der neu geschrieben werden musste. Geben Sie der Entscheidung also höchstens ein paar Wochen.
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.
Wenn Sie eine zweite Meinung zum Stack Ihrer App möchten, geht unser Team für App-Entwicklung ihn mit Ihnen durch. Schicken Sie uns die Eckdaten. Einen ersten Eindruck, was der Bau selbst kostet, gibt Ihnen der App-Kostenrechner.
Häufige Fragen
Welches Cross-Platform-Framework hat die beste Zukunft?
Alle drei haben grosse Firmen dahinter und regelmässige Releases: Google bei Flutter, Meta bei React Native, JetBrains bei Kotlin Multiplatform. Keines sieht so aus, als würde es bald verschwinden. Die sicherere Wette auf lange Sicht ist das Framework, das Ihr Team auch in drei Jahren noch pflegen kann.
Flutter oder Kotlin Multiplatform für eine neue App?
Flutter, wenn Sie noch keine Mobile-Entwickler haben und eine Codebasis samt Oberfläche schnell in beide Stores bringen wollen. Kotlin Multiplatform, wenn Sie schon iOS- und Android-Entwickler beschäftigen und native Screens auf einem gemeinsamen Kern wollen. Mit Compose Multiplatform teilt KMP auch die Oberfläche. Dann bauen Sie Ihren schwierigsten Screen in beiden und vergleichen.
KMP oder React Native: was sollen wir nehmen?
Die beiden beantworten verschiedene Fragen. React Native lässt ein JavaScript-Team eine App schreiben, die echte native Komponenten zeigt. Kotlin Multiplatform lässt native Entwickler die Logik teilen und die Oberfläche jeder Plattform behalten. Entscheiden Sie also nach dem Team, das Sie haben: React-Entwickler sprechen für React Native, Swift- und Kotlin-Entwickler für KMP.
Womit wird die App am kleinsten?
Meist mit Kotlin Multiplatform und nativen Oberflächen, weil jede App zu dem, was eine native App ohnehin mitbringt, nur den gemeinsamen Kotlin-Kern dazubekommt. Flutter und React Native bringen beide eine eigene Laufzeit mit, ihre Apps starten also grösser. Auf günstigen Android-Telefonen mit wenig freiem Speicher kann dieser Unterschied für Nutzer spürbar werden.
