Eine Frage mit eingebautem Denkfehler
“Sollen wir die App in Flutter bauen oder in Kotlin Multiplatform?”
In dieser Frage steckt eine Annahme, die selten ausgesprochen wird: dass beide um denselben Job konkurrieren. Tun sie nicht.
Flutter gibt Ihnen eine Codebasis und malt jedes Pixel selbst. Kotlin Multiplatform gibt Ihnen eine geteilte Logikschicht und überlässt die Pixel der Plattform, solange Sie sich nicht bewusst zusätzlich für Compose Multiplatform entscheiden.
Das ist kein Funktionsunterschied. Das sind zwei verschiedene Theorien darüber, woher der Nutzen plattformübergreifender Entwicklung eigentlich kommt.
Und genau deshalb schauen wir uns KMP deutlich genauer an, als der übliche Framework-Zyklus es rechtfertigen würde.
Was die beiden Ansätze tatsächlich ausliefern
Flutter übersetzt Dart und rendert über eine eigene Engine. Ihr Button ist auf iOS und Android derselbe Flutter-Button, gezeichnet vom selben Code, identisch bis zur Animationskurve.
Einheitlichkeit bekommen Sie geschenkt. Plattformgefühl ist der Posten, den Sie bezahlen.
Kotlin Multiplatform dreht das um. Geteiltes Kotlin wird auf Android zu JVM-Bytecode und auf iOS über Kotlin/Native zu einem nativen Binary. Im gemeinsamen Modul liegt die unglamouröse Hälfte der App: HTTP-Clients, JSON-Parsing, Offline-Synchronisation, Validierung, Preisregeln, der Zustandsautomat, den niemand zweimal schreiben möchte.
Die Screens bleiben nativ. Jetpack Compose auf Android, SwiftUI auf iOS.
Bei Flutter ist also Einheitlichkeit gratis und Nativität teuer. Bei KMP ist Nativität gratis und Einheitlichkeit die Arbeit. Alles Weitere in diesem Vergleich folgt aus diesem einen Satz.
Der Punkt dahinter: In der geteilten Logikschicht sitzen die Fehler, die richtig Geld kosten. Ein Rundungsfehler in der Rabattberechnung, einmal geschrieben, einmal getestet, auf beiden Plattformen identisch. Das ist das ganze Versprechen.
KMP, Flutter und React Native im Vergleich
| Kotlin Multiplatform | Flutter | React Native | |
|---|---|---|---|
| Bauprinzip | Geteilte Kotlin-Logik, native UI je Plattform. Geteilte Oberfläche optional über Compose Multiplatform | Eine Dart-Codebasis, eigene Render-Engine zeichnet jedes Widget | Eine JS/TS-Codebasis, die echte Plattform-Widgets steuert |
| Was Sie teilen | Von einem einzelnen Logikmodul bis zu Logik plus vollständiger Compose-UI. Sie bestimmen die Grenze | Praktisch alles oberhalb des Plattformkanals | Oberfläche und Logik, native Module für die Lücken |
| Reife des Ökosystems | Stabil seit 2023, Compose für iOS stabil seit 2025, Compose für Web weiterhin Beta. Kleinster Bibliotheksbestand der drei | Am tiefsten von allen dreien. Großes Paketregister, langer Anbieterschwanz, Impeller-Umstellung auf Android wird 2026 abgeschlossen | Größter Talentpool über React. Ökosystem breit, und seit 0.82 Ende 2025 gibt es nur noch die New Architecture, der Rückbau der Legacy-Architektur läuft im Hintergrund weiter |
| Personalmarkt DACH | Jede Android-Entwicklerin schreibt die Sprache bereits. iOS-Leute muss man überzeugen | Dart ist eine kleine Sprache mit großem Framework. Flutter-Profile sind verfügbar und wechselbar | Vorhandene React-Teams liefern Mobile in Wochen |
| Wann es gewinnt | Bestehende native Teams, lange Wartungshorizonte, fachlogikschwere Domäne, Ambitionen über Mobile hinaus | Designgetriebenes Produkt, ein kleines Team, Einheitlichkeit schlägt Plattformkonvention | Ihr Webteam ist Ihr App-Team, die Komponentenmuster übertragen sich |
In keiner Zeile steht “am besten”. Das ist Absicht.
React Native fällt in dieser Aufstellung oft hinten runter, und das wird ihm nicht gerecht. Es gewinnt aus einem organisatorischen und nicht aus einem technischen Grund: Wenn Ihr Webteam bereits React schreibt, ist der Weg zur App kürzer als jeder Schulungsplan für Dart oder Kotlin/Native.
Diesen Vorteil hat KMP nicht, und Flutter auch nicht. Wer ihn hat, sollte ihn nutzen.
Wie KMP erwachsen geworden ist
Plattformübergreifende Werkzeuge verdienen sich Vertrauen langsam, und KMP tut das seit Jahren öffentlich.
JetBrains erklärte die Technologie im November 2023 für stabil. Auf der Google I/O 2024 kündigte Google offizielle Unterstützung dafür an, Geschäftslogik mit KMP zwischen Android und iOS zu teilen. Diese Ankündigung wog schwerer als jede Versionsnummer, weil damit Android-Bibliotheken aus erster Hand aufhörten, eine reine Android-Angelegenheit zu sein.
Dann kam der interessante Schritt. Compose Multiplatform für iOS erreichte den Stable-Status mit Version 1.8.0 im Jahr 2025, samt Funktionsgleichstand zu Jetpack Compose für gängige Fälle, typsicherer Navigation und VoiceOver-Unterstützung.
Geteilte Oberflächen waren damit keine Demo mehr.
Die Verbreitung zog nach. Die Developer-Ecosystem-Umfrage von JetBrains weist unter ihren Teilnehmenden für 2025 eine KMP-Nutzung von 18 % aus, nach 7 % im Vorjahr. Dieser Anteil stammt aus einer allgemeinen Stichprobe von 24.534 Entwicklerinnen und Entwicklern, nicht aus einem KMP-Publikum.
Eine Verdopplung innerhalb eines Jahres kommt normalerweise mit einem Sternchen. Hier lautet das Sternchen schlicht: Es hat klein angefangen.
Entscheidend für unsere Lesart ist ohnehin die Produktionsliste. Cash App, Quizlet mit rund 50 Millionen monatlich aktiven Nutzern, Forbes, Philips, Autodesk, Meetup, 9GAG. Das sind keine Pilotprojekte mit Notausgang.
Wann wir dafür plädieren würden
Wir wählen einen Stack nicht, weil er spannend ist, sondern anhand dessen, was beim Kunden ohnehin schon steht. Vier Situationen sprechen deutlich für KMP.
- Es gibt bereits ein Android-Team. Der wichtigste Punkt. Wer Kotlin-Leute hat, kann KMP ohne eine einzige Neueinstellung einführen, weil das geteilte Modul einfach Kotlin ist. Flutter bedeutet im selben Haus: eine Sprache einführen, die bisher niemand produktiv schreibt.
- Die Fachlichkeit wiegt schwerer als die Oberfläche. Versicherungstarife, Tourenplanung, Außendiensteinsätze, Instandhaltung. Überall dort, wo die Regeln das Produkt sind, ist die UI eine dünne Schale über einem dicken Kern. Genau diesen Kern teilt KMP am besten.
- Die App soll acht Jahre laufen. Native Oberflächen altern mit der Plattform. Die Optik einer Flutter-App ist an die ausgelieferte Framework-Version gebunden, und der Anschluss an eine neue iOS-Designsprache ist Ihre Migration.
- Mobile ist nicht das Ende. Kotlin läuft auch im Backend. Ein geteiltes Validierungsmodul, das Android-App, iOS-App und Ktor-Service gemeinsam nutzen, ist keine Folie, sondern baubar.
Der letzte Punkt ist strukturell dasselbe Argument wie bei TypeScript über den gesamten Stack: eine Sprache, ein Denkmodell, ein Typensystem über alle Grenzen. Gleiche Logik, anderes Terrain. TypeScript besitzt die Achse Browser zu Node, Kotlin die Achse Mobile zu JVM.
Der Teil, der in Vergleichsartikeln fehlt
Framework-Vergleiche tun so, als fiele die Entscheidung einmal, am Anfang, mit sauberem Team und ohne Altlasten. Der Fall, den wir tatsächlich sehen, ist unordentlicher.
Der Klassiker: Ein Unternehmen hat eine funktionierende Android-App, dazu eine zwei Jahre später von einem Dienstleister gebaute iOS-App, und eine Supportliste voller Tickets, die sich nur auf einer der beiden reproduzieren lassen. Die Angebotslogik widerspricht sich, weil sie zweimal von zwei Personen geschrieben wurde, die nie miteinander gesprochen haben.
Der ehrliche Preis dafür lautet bei Flutter: zwei Neuentwicklungen und ein eingefrorenes Design. Bei KMP lautet er: ein Fachmodul herauslösen, zuerst in die Android-App bringen, dann in die iOS-App, ohne dass eine der beiden Apps dunkel wird.
Der zweite Weg ist unspektakulär und langsam. Er überlebt dafür den Kontakt mit einer Roadmap, auf der noch anderes steht. Wer die Rechnung dazu sehen will, findet sie in unserem Beitrag zu den wahren Kosten technischer Schulden.
Das ist der eigentliche Grund für unser gestiegenes Interesse. Keine Benchmarks. Die Form der Migration.
Dem gegenüber steht eine Lernkurve, die man nicht kleinreden sollte: Das Build-Setup ist fummeliger als ein Flutter-Projekt, die Gradle-Konfiguration überrascht Leute, und jemand im Team muss verstehen, was expect/actual bedeutet, bevor der erste Sprint endet. Planen Sie das ein, sonst taucht es später als Geschwindigkeitsproblem verkleidet wieder auf.
Wie ein erster Schnitt aussehen würde
Wer KMP ausprobieren will, sollte nicht mit der Oberfläche anfangen. Der risikoärmste Einstieg ist ein einzelnes Modul, das heute schon zweimal existiert und dessen Korrektheit messbar ist.
Gute Kandidaten sind Preis- oder Tarifberechnungen, Formularvalidierung und alles, was mit Offline-Synchronisation zu tun hat. Schlechte Kandidaten sind Kamera, Push-Benachrichtigungen und Kartenintegration, weil dort die Plattformunterschiede der eigentliche Inhalt sind.
Der Prüfstein: Lässt sich das Modul mit einer Testsuite absichern, die auf beiden Plattformen dasselbe Ergebnis erwartet? Wenn ja, ist es ein Kandidat. Wenn nein, ist es Oberfläche und bleibt besser nativ.
Ein solcher Schnitt kostet Wochen, nicht Quartale, und er beantwortet die eigentliche Frage: Trägt Ihr Team die Werkzeugkette? Das lässt sich aus keinem Vergleichsartikel ablesen, auch nicht aus diesem.
Was uns abhalten würde
Jetzt die ehrliche Hälfte.
Der Bibliotheksbestand ist dünner, und das trifft an unspektakulären Stellen. Zahlungen, Karten, Analytics-SDKs, Video: Bei jedem Punkt lautet die Frage, ob ein gepflegter KMP-Wrapper existiert, ob ihn eine einzelne Person betreut, oder ob Sie den expect/actual-Kleber selbst schreiben. Flutters Register hat für fast alles ein Paket und ein Jahrzehnt an Antworten dahinter.
Zweitens ist die iOS-Erfahrung weiterhin die schwächere Seite. Die Swift-Interoperabilität lief bisher über eine Objective-C-Brücke, und die ist undicht: Sealed Classes, Default-Argumente und Coroutines kommen in Swift weniger idiomatisch an, als sie sollten. Der direkte Swift-Export behebt das und wechselt laut der im August 2026 veröffentlichten Kotlin-Roadmap von Alpha auf Beta.
Alpha auf Beta. Nicht ausgeliefert.
Drittens wird ein wirklich iOS-getriebenes Team sich wehren, und zwar zu Recht. Swift-Leute zu bitten, ein generiertes Framework einzubinden und sich in Xcode durch kompilierte Kotlin/Native-Frames zu debuggen, ist eine echte Steuer, gezahlt von denen, die den Wechsel nicht wollten. JetBrains weiß das: Eine bessere Xcode-Anbindung des Kotlin/Native-Debuggers steht auf derselben Roadmap wie der Swift-Export.
Viertens ist Compose Multiplatform für Web weiterhin Beta. Wenn Ihnen jemand “einmal schreiben, auf Mobile, Desktop und im Browser laufen lassen” verkauft, fragen Sie, welches dieser Ziele das Beta-Schild trägt.
Und fünftens etwas, das nichts mit Technik zu tun hat: Bekommen Sie die Leute? Flutter hat im DACH-Raum einen sichtbaren, gut vermarkteten Talentpool. Der KMP-Pool besteht im Kern aus guten Kotlin-Leuten, die Lust darauf haben, und das ist ein kleinerer Kreis, als die Verbreitungszahlen vermuten lassen.
Wo uns das hinstellt
Nicht umgestiegen. Beobachtet.
Für einen Kunden ohne Mobile-Team, mit designgetriebenem Produkt und knappem Zeitplan bleibt Flutter die Empfehlung, aus den Gründen, die wir in wann wir Flutter gegenüber React Native wählen beschrieben haben. Nichts an der Position von KMP im Jahr 2026 ändert daran etwas.
Verändert hat sich das Gespräch mit der anderen Sorte Kunde: dem mit einer laufenden Android-App, einer iOS-App, die davon wegdriftet, und einem Domänenmodell, das zweimal implementiert wurde und sich an drei Stellen selbst widerspricht. Vor zwei Jahren hieß die Antwort dort “beides in Flutter neu bauen”, und alle zuckten zusammen. Jetzt gibt es eine Antwort, die die nativen Apps stehen lässt.
Worauf wir warten, ist der Stable-Status des Swift-Exports. Dieser eine Meilenstein verwandelt KMP von “ausgezeichnet für Android-Teams, die auch iOS ausliefern” in “wirklich neutral zwischen beiden Plattformen”, und der Unterschied zwischen diesen beiden Sätzen entscheidet, ob ein iOS-Lead nickt oder die Arme verschränkt.
Bis dahin lautet unsere Einschätzung: KMP ist für eine engere Auswahl an Projekten richtig, als seine Fans behaupten, und für eine breitere, als die 18 % Verbreitung nahelegen. Wenn Ihre geteilte Logik mehr wert ist als Ihre geteilten Pixel, verdient es einen ernsthaften Blick.
Wenn es umgekehrt ist, steht Flutter weiterhin bereit.
Steht bei Ihnen eine Plattformentscheidung an, mit der Sie Jahre leben müssen? Sprechen wir darüber. Wir schauen uns Ihr Team, Ihre Fachlichkeit und Ihren Zeitplan an und sagen Ihnen ehrlich, auf welcher Seite dieser Linie Sie stehen.