Flutter und Kotlin Multiplatform beantworten dieselbe Frage mit entgegengesetzter Philosophie. Flutter sagt: Teile alles — eine Codebasis für Logik und Oberfläche, gezeichnet vom eigenen Renderer, identisch auf jedem Gerät. Kotlin Multiplatform sagt: Teile, was sich lohnt — die Geschäftslogik einmal in Kotlin, die Oberfläche nativ pro Plattform oder, wenn gewünscht, per Compose Multiplatform ebenfalls geteilt. Keiner der Ansätze ist „besser“; sie passen zu verschiedenen Ausgangslagen. Beim Duell Flutter gegen React Native war unsere Antwort die Team-Frage — hier ist es die Frage, was ihr schon habt.
Die Ausgangslage schlägt das Datenblatt
Der häufigste Fehler in dieser Debatte ist, sie abstrakt zu führen. Drei typische Ausgangslagen:
Ihr habt bereits native Apps und ein Android-Team. Dann ist KMP fast immer der bessere Weg. Die Geschäftslogik wandert Modul für Modul in gemeinsames Kotlin, die gewachsenen nativen Oberflächen bleiben, nichts wird weggeworfen. Flutter würde hier einen Neubau bedeuten — und Neubauten funktionierender Apps brauchen einen besseren Grund als Framework-Begeisterung.
Ihr startet auf der grünen Wiese und wollt schnell auf beide Plattformen. Dann spielt Flutter seine Stärken aus: alles einmal bauen, ein ausgereiftes Ökosystem an fertigen Paketen, identische Optik überall, Web und Desktop aus derselben Codebasis dazu. Genau für diese Lage setzen wir auf Flutter.
Ihr wollt natives Look-and-feel, aber keine doppelte Logik. Das ist die KMP-Nische, die Flutter nicht besetzen kann: SwiftUI auf iOS, Jetpack Compose auf Android, darunter ein gemeinsamer Kern für Daten, Netzwerk und Regeln. Der Preis sind zwei UI-Codebasen.
Compose Multiplatform verschiebt die Grenze
Lange lautete die einfache Formel „Flutter teilt die UI, KMP nicht“. Sie stimmt so nicht mehr: Compose Multiplatform bringt geteilte Oberflächen auch in die Kotlin-Welt, inzwischen stabil bis iOS. Damit kann ein KMP-Projekt heute dieselbe Vollteilung erreichen wie Flutter.
Die ehrliche Einordnung dazu: Das Flutter-Ökosystem hat mehrere Jahre Vorsprung an Paketen, Werkzeugen und gelösten Problemen. Wer volle UI-Teilung will, bekommt sie mit Flutter heute mit weniger Reibung; wer sie mit Compose Multiplatform baut, ist früher dran und stolpert öfter über fehlende Bausteine. Dieser Abstand schrumpft — aber er existiert, und Projektpläne sollten ihn einpreisen.
Woran ihr die Entscheidung festmacht
Vier Fragen genügen fast immer. Was kann das Team? Eine Kotlin-Vergangenheit spricht für KMP; gemischte oder junge Teams lernen Dart schneller als das native Doppel. Was existiert schon? Bestands-Apps sprechen für KMP, die grüne Wiese für Flutter. Wie wichtig ist Plattformtreue? Wer natives Verhalten je Plattform will, landet bei KMP mit nativen UIs. Und wie viele Zielplattformen sollen es sein? Sobald Web oder Desktop ernsthaft dazukommen, wird Flutters Komplettpaket schwer zu schlagen.
Wer nach diesen vier Fragen noch unentschieden ist, hat meist ein Projekt, das mit beidem funktioniert — dann hilft ein nüchterner Blick von außen weiter.
Ihr steht vor genau dieser Wahl? Schreib mir — ihr bekommt eine Empfehlung, die zu eurem Team und eurem Bestand passt, nicht zur Lieblingstechnologie des Beraters.