Kopenhagen ist immer eine Reise wert, vor allem wenn man dabei noch so viel lernen kann! Nachdem in den letzten Jahren die KotlinConf Tickets zu schnell vergriffen waren, habe ich dieses Mal schon im Vorjahr bei den Tickets zugeschlagen – und dank unseres flexiblen Fortbildungsbudgets fällt die Entscheidung, zusätzlich den “Kotlin Multiplatform beyond basics“-Workshop zu buchen.
Auf der jährlichen Konferenz zu all things kotlin ist Multiplatform das große Thema. Rund 21 der über 100 Talks tragen Multiplatform im Titel, und das zurecht: Es ist der aus meiner Sicht erste vielversprechende Ansatz, Code & UI über mobile Plattformen und das Web hinweg zu sharen und dabei keine neue Programmiersprache zu lernen, JavaScript schreiben zu müssen, oder die Native App zu einem besseren Webbrowser zu degradieren. Und das Beste: Man muss nicht alles neu schreiben; die bestehende Android-Implementierung kann (bei entsprechendem Modernisierungsgrad und klug gewählten Library Abhängigkeiten) weiter genutzt werden.
Da das Thema Multiplatform bei allen businessgetriebenen Entscheider*innen in der Regel auf offene Ohren stößt (Geld sparen will schließlich jede/r), aber leider oft unrealistische Erwartungshaltungen weckt (nein, das Android Team macht die Arbeit ab jetzt nicht alleine) und auch nicht klar ersichtliche Transformationsaufwände birgt (nein, euer Custom Bluetooth Protokoll funktioniert mit unserem Framework nicht out-of-the-box), erhoffe ich möglichst viele Erfahrungswerte der Developer-Community auf der Konferenz mitzunehmen. Um sinnvoll beraten zu können, kann man schließlich auch von den Erfahrungswerten anderer lernen.
Der Workshop von Pamela Hill und Constantin Tskhovrebov findet mit ca. 40 Teilnehmer*innen statt und geht über den kompletten Dienstag.
Erste Erkenntnis: Compose ist ein UI-Framework, mit dem man in deklarativer Form UIs entwickeln kann. Es gibt einen Unterschied zwischen Jetpack Compose (= Compose für Android von Google) und Compose Multiplatform (= Compose für alle anderen von Kotlin unterstützten Plattformen von JetBrains). Kotlin Multiplatform bietet die Grundlage für Compose Multiplatform, aber kann abseits von UI auch beliebigen Code (z. B. Business Logik) auf den unterstützten Plattformen teilen.
Dann wird es offiziell: Mit der Keynote startet die eigentliche Konferenz. Mit dem in der Tech Welt üblichen Brimborium wird das neueste Kotlin 2.0 Release angekündigt. AWS, Meta und Google geben Updates zum Stand der Kotlin-Adaption, Google Workspace verwendet Kotlin Multiplatform, das Google Monorepo enthält nun 35 Millionen Zeilen Kotlin Code, es gibt neue KMP-ready Jetpack Libraries und man arbeitet am direkten Kotlin-to-Swift-Export.
Auf insgesamt sechs Tracks sprechen in den nächsten beiden Tagen nun 100 Speaker über das Kotlin-Ökosystem. Der schieren Menge an Informationen gerecht zu werden, würde den Rahmen dieses Beitrags sprengen.
Neugierig? Hier geht's zur Keynote auf der Kotlin Conference:
Für uns als Mobile Developer und Berater*innen gehört die Einordnung neuer Technologien zu unserem Tagesgeschäft. Da unsere Developer bei unterschiedlichen Kunden tätig sind, ist der Zoo an verschiedenen Technologien, die unsere Mobile Teams nutzen, entsprechend groß, und zu den gängigsten Technologien findet man Kolleg*innen, die diese entweder produktiv einsetzen, für einen Kunden evaluiert haben, inwieweit ein Produktiveinsatz möglich wäre oder diese in vergangenen Projekten bereits eingesetzt haben.
Xamarin, Flutter, React Native – es gab und gibt viele Ansätze zum Heben des Multiplatform-Sparpotentials. Vielen davon ist gemeinsam, dass man nie wieder davon gehört hat. Ist also KMP bzw. CMP nur die nächste Iteration im Multiplatform Hypecycle?
Für KMP sprechen aus meiner Sicht, dass keine neue Programmiersprache (wie Dart bei Flutter) gelernt werden muss, weitere Plattformen (Web, Desktop, Backend, smarte Lichtschalter) unterstützt werden und dass die Entscheidung für ein Verproben niederschwelliger ist: Eine Migration bestehender Apps kann schrittweise erfolgen und auch wieviel und welchen Code man teilt, kann flexibel entschieden werden. Außerdem kann man den bestehenden Code wiederverwenden, es erfordert also keine schwierige, nicht rückgängig zu machende, Ganz-oder gar-nicht Entscheidung.
Mit der Ankündigung, dass Compose Multiplatform für iOS in Beta ist und man an einem Kotlin-to-Swift-Export arbeite, fallen zwei Hürden für einen produktiven Einsatz vom KMP bzw. CMP für Projekte, die die iOS-Plattformen betreffen.
Gerade die ObjectiveC-Bridge, die momentan technisch die Brücke zwischen den Plattformen darstellt, ist aus der Sicht unserer iOS-Entwickler*innen noch eine Sollbruchstelle, da – obwohl Kotlin und Swift durchaus ähnlich sind – einige Sprachfeatures der modernen funktionalen Programmiersprachen durch den Umweg über ObjectiveC verloren gehen. Dank dem angekündigten Kotlin-to-Swift-Export könnten diese Einschränkungen bald kein Thema mehr sein. Einen guten Überblick über den Stand der Interoperabilität findet man in der Kotlin-Swift Interopedia.
Bei der Mobile-Entwicklung ist es in der Praxis sehr wichtig, gutes Tooling für asynchrone Abläufe zu haben. In Kotlin verwendet man dazu Coroutines, die eine strukturierte Asynchronität in Kotlin ermöglichen. Diese können über den Einsatz von Libraries wie Touchlab SKIE auch in iOS verwendet werden.
Libraries sind für die Softwareentwicklung grundlegend und immer mehr aus der Android-Welt bekannte Bibliotheken sind KMP-ready und bringen ihre eigenen plattformspezifischen Implementierungen mit. Eine gute Übersicht findet man im KMP Awesome repository, einem GitHub Repository, dass eine gute kategorisierte Übersicht über die meisten Kotlin Multiplatform Libraries gibt. Wer sich für KMP- und CMP-fähige Libraries interessiert, dem sei der Talk von John O`Reilly zu „Hitchhikers Guide to Kotlin Multiplatform Libraries“ empfohlen.
Welche Teile der Applikation man teilt, kann je nach Projektumfeld passend gewählt werden. Ein Teilen der Business- und Netzwerklogik mit nativen UIs ist ebenso möglich wie ein geteiltes Compose-UI. Mithilfe von Community Libraries ist auch die Presentation-Schicht teilbar, also ViewModels oder Controllerklassen.
Viele Talks behandeln die Erfahrungswerte von Early-Adoptern, die über ihre Reise mit KMP berichten. Das Einsparpotential schwankt, 40 Prozent weniger Code und eine Verdopplung der Manager High Fives ist der Erfahrungswert von Instabee.
Nicht alle Herausforderungen auf dem Weg sind technischer Natur: Annyce Davis legt auf der, vorwiegend von Android Entwickler*innen besuchten Konferenz den Fokus auch auf die iOS-Kolleg*innen. Wie arbeitet man als gemischtes Mobile-Team gut zusammen, wie verhandelt man die Schnittstellen, wie ist die Developer Experience in iOS und damit die Akzeptanz auf Seite der iOS-Teams?
Mit der neuen Fleet IDE soll eine Entwicklungsumgebung geschaffen werden, in der sowohl Kotlin als auch Swift Code geschrieben werden kann – gerade für die KMP mit iOS ein wichtiger Aspekt zu Verbesserung der Developer Experience.
Nach GitHub Copilot, Googles Gemini und OpenAIs ChatGPT bietet auch Jetbrains einen KI-Assistenten an, der durch Einbinden des aktuellen Kontextes direkter Integration in die IDE punkten soll. Commit Messages generieren, Tests generieren und einiges mehr sind die versprochenen Features.
Die KotlinConf war dieses Jahr definitiv eine Reise wert. Ich finde es großartig, dass ich jetzt mit Kotlin auch auf Desktop, Web, iOS und smarte Lichtschalter deployen kann, und einen Coding Assistenten von JetBrains würde ich definitiv austesten.
KMP und CMP sind immer validere Optionen bei Projekten, die auf einer Vielzahl von Plattformen identisch funktionieren sollen. Für bestehende Projekte ist die Option einer schrittweisen Portierung ein guter Weg. Spannend ist und bleibt die Akzeptanz des Themas auf Seiten der iOS-Developer-Community. Hier gibt es unterschiedliche Meinungen, was aber auch völlig in Ordnung ist. Das erhoffte Sparpotential wird dazu führen, dass man sich als Mobile Developer mit dem Thema auseinandersetzen muss. Egal ob man als Entwickler*in zur „Open-minded-Generalisten-Fraktion“ gehört, die immer Lust hat, sich eine neue Technologie anzuschauen, oder ob man den ultimativen Qualitätsanspruch an Plattformkonformität als Spezialist*in betont – Geld sparen oder schneller Business Value schaffen möchte schließlich jeder Kunde gerne.