Seit August 2020 bietet JetBrains mit Kotlin Multiplatform Mobile (KMM) ein SDK für die Cross-Platform-Entwicklung gezielt für Android und iOS an. Seit letztem Oktober hat KMM nun den Beta-Status erreicht und ist somit neben Flutter ein weiterer vielversprechender Kandidat, um die Entwicklung von iOS- und Android-Apps effizienter und kostengünstiger zu gestalten. Wir haben uns entschieden, für ein neues internes Projekt auf KMM zu setzen und stellen nun unsere Erfahrungen und Einschätzungen zu dieser Technologie vor.
Was ist und kann KMM?
Kotlin Multiplatform Mobile ist ein Crossplatform-SDK von JetBrains für die Programmiersprache Kotlin. Die Idee dahinter ist, dass geteilter Code in Kotlin geschrieben werden kann und dieser dann in einem Android- und iOS-Projekt eingebunden und verwendet werden kann. Dazu wird der gemeinsame (shared) Code für die jeweilige Zielplattform kompiliert. Für Android bedeutet dies keine Veränderung, für iOS hingegen heisst dies, dass der geteilte Code zu einem nativen Framework kompiliert und dann ins iOS-Projekt eingebunden werden kann (z. B. mit cocoapods).
Das Spannende daran ist, dass sich dieser gemeinsame Code aus Swift heraus (Programmiersprache für die iOS-Entwicklung) nahtlos aufrufen lässt, der Entwickler merkt kaum, dass es sich nicht um eine herkömmliche Swift-Library handelt. Wie viel Code eines Projektes nun in den shared-Teil gepackt wird und was jeweils im Android- und iOS-Projekt getrennt geschrieben wird, kann völlig frei entschieden werden. Im nächsten Abschnitt stellen wir daher unseren Ansatz vor und möchten die Vor- und Nachteile dieser Umsetzung erläutern.
App-Architektur mit KMM
In den letzten Jahren hat sich die iOS- und Android-Entwicklung einander immer mehr angenähert. Konzepte wurden voneinander übernommen oder haben sich aufgrund von Trends in die ähnliche Richtung entwickelt. Durch diese Tatsache bietet es sich an, in einem KMM-Projekt möglichst viel Code in den gemeinsamen Shared-Teil zu bringen, um so die restliche rein native iOS- und Android-Entwicklung möglichst schlank zu halten. Die folgende Grafik soll dazu einen Überblick geben. Auch wenn man sich unter den einzelnen Komponenten vielleicht nicht so viel vorstellen kann, so verdeutlicht die Grafik doch, dass sich in dem von uns gewählten Ansatz der meiste Code im Shared-Teil befindet. Einzig die Umsetzung der UIs wird getrennt für die beiden Plattformen gemacht. Das hat natürlich den Vorteil, dass man das meiste nur einmal umzusetzen und auch zu testen braucht.
Wie bereits erwähnt, gibt es jedoch keine Vorgaben, was genau alles in den Shared-Teil gehören soll. Wenn dieser Aufbau für ein bestimmtes Projekt nicht geeignet ist, kann eine passendere Strukturierung gewählt werden. Diese Flexibilität ist ein großer Pluspunkt von KMM.
Erfahrungen mit KMM
KMM ist zwar noch immer in der Beta-Phase, funktioniert jedoch bereits sehr stabil. Für Entwickler, die aus der Android-Welt kommen, sind die Hürden sehr gering. Für sie funktioniert fast alles wie gewohnt. Einzig bei Bibliotheken für Datenbankzugriffe oder der Kommunikation mit einem Backend müssen sie auf Alternativen zurückgreifen (in unserem Fall SQLDelight und Ktor). Für iOS-Entwickler sieht die Sache etwas komplizierter aus: Wenn sie sich an der Entwicklung des Shared-Teils beteiligen wollen, müssen sie sich natürlich in die Kotlin-Welt einarbeiten. Darüber hinaus funktioniert die IDE-Unterstützung für den Code aus dem Shared-Teil eher mäßig, was im Alltag ein wenig ärgerlich sein kann. Das bedeutet, dass die Fehlersuche beim Entwickeln mitunter etwas schwieriger ist.
Abgesehen von diesen Hürden haben wir bisher durchwegs positive Erfahrungen mit KMM und auch der von uns gewählten Strukturierung gemacht. Beinahe die gesamte Logik konnten wir als geteilten Code erstellen und so die Entwicklungszeit minimieren. Die erforderlichen Kompromisse, die dadurch gemacht werden müssen, damit sich der Shared-Teil in die iOS- und Android-Welt integrieren lässt, sind dabei minimal. Gerade der Umstand, dass es sich bei den beiden UI-Technologien (SwiftUI für iOS und Jetpack Compose für Android) um deklarative UI-Technologien handelt, erleichtert ein gemeinsames Schnittstellendesign erheblich. Ein weiterer spannender Aspekt von KMM ist, dass plattformspezifische Implementierungen (zum Beispiel das Abspeichern von einfachen Daten auf dem jeweiligen Dateisystem) direkt in Kotlin im Shared-Teil gemacht werden können. Für die Android-Welt ist das natürlich nichts Besonderes, aber das Gleiche gilt eben auch für iOS mit Swift. Das bedeutet, dass einfache Implementierungen direkt in Kotlin geschrieben werden können, indem Elemente aus dem iOS Foundation-Framework verwendet werden.
Fazit
Neben Flutter und anderen Alternativen bietet KMM eine weitere sehr spannende Möglichkeit für die plattformübergreifende Entwicklung. Wenn wir nun die drei Technologien vergleichen, die für uns besonders interessant sind, ergibt sich der folgende vereinfachte Vergleich:
KMM
Vorteil: Flexibel, UIs können individuell, pixelgenau und native umgesetzt werden, bei technischen Problemen kann immer auf eine native Umsetzung ausgewichen werden.
Nachteil: zur Zeit noch Beta, Zusammenarbeit zwischen iOS- und Android-Entwicklern muss gut koordiniert werden.
Flutter
Vorteil: Im günstigsten Fall kann eine App einmal entwickelt werden und läuft auf beiden OS. Das UI kann ebenfalls einmal entwickelt werden und sieht auf beiden OS gut aus.
Nachteil: Bei plattformspezifischen Anforderungen muss man auf Libraries zurückgreifen oder selber die jeweiligen Umsetzungen machen, das kann sehr aufwändig sein, siehe unseren Beitrag dazu.
