Teil 4 – Der neue Mittelweg: Kotlin Multiplatform & Compose Multiplatform

Es gibt Ansätze, die man erst belächelt – und ein Jahr später produktiv einsetzt. Kotlin Multiplatform gehört für mich in diese Kategorie. Was JetBrains da in den letzten Jahren aufgebaut hat, ist kein weiteres Cross-Platform-Versprechen mit glänzender Oberfläche und brüchigem Fundament. Es ist ein durchdachter Mittelweg, der sich von Flutter und React Native fundamental unterscheidet – und genau deshalb einen eigenen Artikel verdient.

Die Grundidee: Teile, was teilbar ist

Kotlin Multiplatform – kurz KMP – verfolgt keine Einheitslösung. Das Framework zwingt dich nicht, die gesamte App in einer gemeinsamen Codebasis zu verwalten. Stattdessen konzentriert es sich auf das, was plattformübergreifend tatsächlich Sinn ergibt: die Geschäftslogik. Netzwerkaufrufe, Datenbankzugriffe, Datenmodelle, Validierungslogik – das alles wandert in ein gemeinsames Kotlin-Modul. Die UI bleibt nativ: Swift auf iOS, Jetpack Compose auf Android.

Das klingt nach einem Kompromiss, ist aber eigentlich das Gegenteil. Statt überall 80 Prozent zu liefern, liefert KMP an den richtigen Stellen 100 Prozent – und lässt die Plattform dort glänzen, wo sie es am besten kann.

Compose Multiplatform: Wenn die UI doch mitmacht

JetBrains geht inzwischen noch einen Schritt weiter. Compose Multiplatform erweitert Jetpack Compose – Googles deklaratives UI-Framework für Android – auf iOS, Desktop und Web. Damit rückt KMP näher an Flutter heran, ohne dessen Rendering-Ansatz zu kopieren. Auf Android läuft Compose nativ, auf iOS setzt Compose Multiplatform auf eine eigene Rendering-Schicht – ähnlich wie Flutter, aber eben auf Basis einer Technologie, die Android-Entwickler bereits kennen und schätzen.

Wer also bereits mit Jetpack Compose auf Android arbeitet, muss keine neue Sprache lernen, kein neues Paradigma verinnerlichen. Die Konzepte sind dieselben – Composables, State, Side Effects. Das senkt die Einstiegshürde erheblich, und das ist kein Marketingargument, sondern gelebte Praxis.

Noch Baustelle – aber welche Art von Baustelle?

Ehrlichkeit ist hier angebracht: Kotlin Multiplatform und Compose Multiplatform sind nicht fertig. Compose Multiplatform für iOS trägt offiziell das Label „Alpha“ beziehungsweise „Beta“, je nach Komponente. Das bedeutet: API-Änderungen sind möglich, manche Features fehlen noch, und das Debugging auf iOS erfordert gelegentlich Geduld.

Aber – und das ist entscheidend – es ist eine Baustelle mit klar erkennbarem Plan und sichtbarem Fortschritt. JetBrains liefert regelmäßig, die Community wächst, und erste Unternehmen setzen KMP bereits produktiv ein: Netflix zum Beispiel nutzt KMP für geteilte Businesslogik, und auch bei Touchlab und anderen spezialisierten Agenturen ist KMP längst Alltag. Eine Baustelle, auf der schon fleißig gewohnt wird, ist eben etwas anderes als eine Baustelle, auf der der Rohbau noch auf den Statiker wartet.

KMP vs. Flutter vs. React Native: Wer konkurriert hier eigentlich mit wem?

Die Frage stellt sich zwangsläufig – und die Antwort überrascht vielleicht. KMP konkurriert nicht wirklich mit Flutter oder React Native, jedenfalls nicht direkt. Flutter ersetzt die gesamte native UI, React Native abstrahiert sie. KMP ergänzt sie. Wer ein bestehendes Android-Team hat und iOS hinzunehmen möchte, ohne die gesamte Codebasis umzuschreiben, für den ist KMP eine Option, die Flutter schlicht nicht bieten kann.

Aus der Ingenieursperspektive ist das ein vertrautes Muster: Man nimmt nicht das leistungsstärkste Werkzeug, sondern das passendste. Ein Oszilloskop ersetzt keinen Logikanalysator – beide haben ihren Platz auf dem Labortisch.

Was mich persönlich überzeugt

Ich habe AuraHarmony – meine App für Solfeggio-Frequenzen und Binaural Beats – in Kotlin und Jetpack Compose entwickelt. Der Gedanke, Teile dieser Codebasis auf iOS portieren zu können, ohne von vorn anzufangen, hat etwas ausgesprochen Attraktives. KMP würde genau das ermöglichen: Die Audiologik, die Datenbankschicht, die Einstellungsverwaltung – das alles könnte geteilt werden, während die UI auf beiden Plattformen nativ bleibt.

Das ist kein theoretisches Szenario. Es ist der Weg, den ich für die nächste Ausbaustufe der App ernsthaft in Betracht ziehe – und genau deshalb beschäftigt mich KMP gerade mehr als jedes andere Framework in dieser Serie.

Fazit für Teil 4

Kotlin Multiplatform ist kein Allheilmittel, und Compose Multiplatform ist noch nicht da, wo es in zwei Jahren sein wird. Aber die Richtung stimmt, das Fundament ist solide, und der Ansatz ist ehrlicher als so manches Versprechen aus der Cross-Platform-Welt. Wer bereits in der Kotlin-Welt zuhause ist, sollte KMP auf dem Radar haben – nicht als Experiment, sondern als ernstzunehmende strategische Option.

Teil 5 bringt dann das Fazit: Was würde ich heute wählen – und warum?