5 Auswertung und Vergleich
Kotlin Multiplatform ist eine Ergänzung zu der reinen nativen Entwicklung und schränkt diese nicht ein. Der Umfang an geteiltem Code ist flexibel, denkbar ist alles, von einer einzelnen Klasse bis hin zu der gesamten Business-Logik der Anwendung. Sollte sich etwas aus technischen Gründen nicht plattformübergreifend umsetzen lassen (z.B. die UI, Navigation, Kamera), kann diese Funktionalität stattdessen nativ programmiert werden. Die Technologie Kotlin Multiplatform bietet den gleichen Funktionsumfang wie die reine native Entwicklung, da bei Bedarf auf diese zurückgegriffen werden kann.
Die Benutzeroberflächen werden in Kotlin Multiplatform Projekten separat für jede Plattform entwickelt. Bildschirmfotos der Benutzeroberfläche der Use-Case App befinden sich im Anhang B (Abbildungen 8 bis 16). Es werden die UI-Elemente des jeweiligen Betriebssystems verwendet. Der Nutzer kann dadurch nicht erkennen, ob in einer App Code zwischen Android und iOS geteilt wurde oder nicht. Die Technologie Kotlin Multiplatform und die reine native Entwicklung bieten das gleiche Nutzererlebnis bezüglich UI und Interaktion.
Die Performanz von Kotlin Multiplatform kann sich mit jedem Release verändern, da sich die Technologie derzeit in der Entwicklung befindet. Während der normalen Bedienung ist kein Unterschied in der Performanz zwischen den nativen und den mit Kotlin Multiplatform entwickelten Use-Case Apps für den Anwender wahrnehmbar. Dazu wurden die Apps auf Endgeräten in unterschiedlichen Preissegmenten getestet (Google Pixel 3, Samsung Galaxy S8, Huawei P9, Nexus 5, iPhone X, iPhone 6s). Eine genaue Untersuchung der Startzeit von Kotlin Multiplatform und nativen mobilen Anwendungen ist ein Schwerpunkt der Arbeit von Evert (2019). Dazu werden 100 Messungen pro App durchgeführt mit dem Ergebnis, dass Kotlin Multiplatform Anwendungen auf Android-Geräten langsamer als native Apps starten, die gemessene Differenz ist kleiner als 100 Millisekunden (Evert, 2019, S. 28f). Auf iOS-Geräten konnte kein signifikanter Unterschied festgestellt werden (Evert, 2019, S. 36). Basierend auf diesen Ergebnissen ist der Unterschied in der Performanz relativ gering, zumindest wenn davon ausgegangen wird, dass die Ergebnisse auf die Performanz der gesamten App übertragbar sind. Es hängt von der jeweiligen Situation ab, wie stark das Nutzererlebnis dadurch beeinträchtigt wird. Komplexe Aufgaben wie z.B. die Verschlüsselung einer Datei können spürbar länger dauern. Bei den meisten Anwendungsfällen wird der Unterschied kaum zu bemerken sein, da hier die Reaktionszeit des Nutzers oder die Geschwindigkeit des Netzwerks der limitierende Faktor sind.
Kotlin Multiplattform Apps sind größer als native Anwendungen, wobei ein deutlicher Unterschied zwischen Android und iOS vorhanden ist. Die Technologie Kotlin Multiplatform erzeugt für die Use-Case App eine um 9% größere APK und eine um 400% größere IPA. Entsprechend wird auch mehr Speicherplatz benötigt, auf Android Geräten ca. 8% und auf iOS Geräten ca. 700% mehr (siehe Tabelle 4 sowie Anhang C.1, Tabellen 6 und 7).
| Nativ | Kotlin Multiplatform | |
|---|---|---|
| APK | 5,66 MB | 6,17 MB |
| IPA | 0,28 MB | 1,40 MB |
Tabelle 4 – Vergleich benötigter Speicherplatz
Für genauere Untersuchungen wurden aus der Use-Case App mehrere separate Anwendungen erstellt, die jeweils nur einen einzigen Use-Case sowie die Seiten „Use-Case-Auswahl“, „Vergleich“ und „Info“ enthalten. Die Ergebnisse (siehe Anhang C.2, Tabellen 8 und 9) zeigen, dass ein und derselbe Use-Case sowohl viel als auch wenig Speicherplatz benötigen kann, je nach Betriebssystem. Eine Ursache lässt sich darüber hinaus aber nicht sicher identifizieren. Die Größendifferenz zwischen nativer und Kotlin Multiplatform App könnte auf die unterschiedlichen Libraries in beiden Projekten zurückzuführen sein. Ein möglicher Grund für die Größe der iOS Apps könnte Kotlin/Native darstellen, da für die Kompatibilität zwischen Objective-C und Kotlin zusätzliche Klassen und Methoden benötigt werden (z.B. KoltlinInt). Denkbar ist auch, dass der Code im Apple Framework noch nicht optimiert bzw. korrekt komprimiert wird. Insgesamte kann der Größenunterschied in Android vernachlässigt werden, in iOS stellt dieser jedoch eine starke Einschränkung im Nutzererlebnis dar.
Ein Kotlin Multiplatform Projekt benötigt zwei Entwicklungsumgebungen. Der Kotlin Code, d.h. die Android App sowie der zwischen beiden Plattformen geteilte Code, wird mit Android Studio erstellt, der Swift Quellcode, d.h. die iOS-App, mit Xcode.
Die Installation der Entwicklungsumgebungen ist in kurzer Zeit möglich. Die benötigten Plugins, mit Ausnahme der beiden Xcode Plugins für das Debuggen, werden von Gradle verwaltet und müssen nicht installiert werden. Das Projekt muss manuell mit beiden IDEs eingerichtet werden, es gibt keine Vorlagen oder sonstige Unterstützung. Ein mit Android Studio erzeugtes Android App-Projekt dient als Ausgangspunkt. Die Struktur muss angepasst und Ordner sowie Packages für den geteilten Code ("commonMain", "androidMain", "iosMain", "commonTest") müssen ergänzt werden. Das iOS-App Projekt wird mit Xcode in einen Unterordner angelegt. Das Multiplattform Gradle-Plugin dient zur Konfiguration. Hier sind die Zielplattformen (Android und iOS), die Quellcode-Verzeichnisse und deren Abhängigkeiten untereinander sowie zu Libraries beschrieben. Der Gradle-Task zur Erstellung des Apple Frameworks ist kein Bestandteil des Plugins. Er muss manuell definiert werden, eine Alternative ist das CocoaPods-Plugin. Während der Einrichtung war es notwendig, die Entwicklungsumgebungen mehrfach neu zu starten, da Änderungen nicht sofort übernommen wurden. Auch existieren vereinzelt Darstellungsprobleme, z.B. wurden Ordner nicht immer als solche erkannt, die Funktionalität wurde dadurch jedoch nicht eingeschränkt. Insgesamt ist die Projekteinrichtung sehr zeitintensiv. Zwei separate Projekte müssen angelegt, konfiguriert und verknüpft werden, dies muss außerdem von Android und iOS Entwicklern gemeinsam vorgenommen werden. Die offizielle Dokumentation geht nur selten über ein Hello-World Programm hinaus, sodass man während der Einrichtung auf Projekte anderer Entwickler angewiesen ist und viel ausprobieren muss.
Ein elementares Hilfsmittel, um das Verhalten von Programmen zu untersuchen und Fehler zu finden, ist ein Debugger. Der Android-Code eines Multiplatform Projekts kann zuverlässig und ohne Aufwand mit einem Debugger analysiert werden. Dies ist darauf zurückzuführen, dass in „iosMain“ und „androidMain“ Kotlin Quellcode enthalten ist. Die Sprache wird auch zur Entwicklung von nativen Android Apps eingesetzt, Android Studio bietet dadurch umfassende Unterstützung an. Der normale Debugger kann verwendet werden, alle Funktionen wie das Setzen von Haltepunkten im Code, Auslesen von Werten oder das Springen zur nächsten Anweisung sind nutzbar.
Der iOS-Quellcode eines Multiplatform Projekts lässt sich nur unzuverlässig und mit viel Aufwand untersuchen. Der Kotlin Quellcode aus „commonMain“ und „iosMain“ wird mit Kotlin/Native kompiliert. Der Compiler sammelt Informationen, damit nach dem Kompilieren eine Zuordnung zwischen ausgeführtem Code (kompiliert) und originalem Quellcode (nicht kompiliert) möglich ist. Diese Beziehung wird in dem standardisierten Debugging Format DWARF 2 beschrieben (JetBrains, 2018, Abschnitt Debugging). Xcode verwendet den Debugger LLDB, der zwar DWARF 2 unterstützt, aber kein Kotlin. Die Firma Touchlab hat mehrere Xcode-Plugins geschrieben, die das Debuggen mit der IDE grundsätzlich ermöglichen. Die Dokumentation des Plugins xcode-kotlin deutet aber an, dass Schnittstellen verwendet werden, die nicht offiziell von Apple dafür vorgesehen sind. Es kann bei jedem neuen Update der IDE sein, dass das Plugin nicht mehr funktioniert oder dessen Einsatz sogar aktiv von Apple unterbunden wird. Während der Erstellung dieser Arbeit hat das Plugin z.B. nach dem Update von Xcode 11.1 auf 11.2 für einige Zeit nicht mehr funktioniert. Eine Alternative sind Konsolen-Debugger, zum Beispiel kann LLDB von der Konsole aus verwendet werden. Dies ist sehr aufwendig und zeitintensiv. Hierbei kam es zu dem Problem, dass Datentypen und Werte von Variablen nicht immer ausgelesen werden konnten.
JetBrains bietet mit AppCode seit mehreren Jahren eine eigene kostenpflichtige IDE zur Entwicklung von iOS-Apps an. Sie unterstützt Multiplatform und das Debuggen in Kotlin/Native seit Version 2019.1 (Petrenko, 2019). In der Praxis wird AppCode jedoch kaum eingesetzt, in dem Forum Stack Overflow finden sich beispielsweise nur 199 Fragen zu AppCode, aber über 130.000 Fragen zu Xcode.
In diesem Abschnitt wird analysiert, wie viel Zeit für das Bauen einer App, d.h. das Erstellen einer Installationsdatei (APK bzw. IPA) aus dem Quellcode, notwendig ist. Alle Messungen fanden unter denselben Bedingungen statt. Mit einem MacBook Pro 2018 (2,6 GHz 6-Kern Intel i7, 16 GB Arbeitsspeicher) wurden jeweils 10 Messungen durchgeführt und der Mittelwert daraus bestimmt.
Während der Entwicklung ist die für das Anwenden von Änderungen benötigte Zeit relevant. Die Installationsdatei muss hier nicht immer komplett neu erstellt werden, da die Entwicklungsumgebung Teile des bereits kompilierten Codes im Cache speichert und wiederverwendet. Dieser Mechanismus funktioniert grundsätzlich auch in Kotlin Multiplatform Projekten. Einzige Ausnahme ist hier, dass das Apple Framework bei Änderungen im geteilten Code immer komplett neu gebaut werden muss, dies dauert bei der Use-Case App ca. 36 Sekunden.
Die für einen normalen Build der App (Clean Build) benötigte Zeit ist relevant, wenn Versionen für den Kunden oder den Store gebaut werden. Der Einsatz von Kotlin Multiplatform bei der Use-Case App hat für Android keinen Einfluss auf die benötigte Zeit, in iOS dauert das Erstellen der Installationsdatei hingegen ca. siebenmal so lange. Insgesamt wird vor allem in iOS durch Kotlin Multiplatform mehr Zeit für das Bauen der App benötigt, als bei der Verwendung nativer Technologien.
Die Technologie Kotlin Multiplatform ist als "moving fast" (MF) gekennzeichnet, d.h. es kann laut JetBrains jederzeit zu grundlegenden Änderungen kommen und keine Stabilität gewährleistet werden (JetBrains, o.J.e). Auch Kotlin/Native Binärdateien sind als MF markiert und nicht abwärtskompatibel (JetBrains, o.J.e). Problematisch ist dies bei der Verwendung von Libraries, da alle Abhängigkeiten sowie das Projekt selbst ein und dieselbe Kotlin/Native Version einsetzen müssen. Nach dem Update von Kotlin/Native 1.3.50 auf 1.3.60 haben beispielsweise einzelne Libraries, die in der Use-Case App verwendet wurden, die neue Version nicht unterstützt, dadurch konnten auch alle anderen nicht aktualisiert werden. Nicht alle eingesetzten Werkzeuge funktionieren zuverlässig. Neben vereinzelten Darstellungsfehlern stellen besonders die in Abschnitt 5.3.2 beschriebenen Herausforderungen beim Debuggen mit Xcode eine große Einschränkung dar.
Zusammenfassend reicht die Zuverlässigkeit und Stabilität noch nicht für einen Einsatz in Kundenprojekten aus. Hier ist nach wie vor die reine native Entwicklung zu bevorzugen.
Die Zeit, die für die Entwicklung einer App benötigt wird, ist zu einem großen Teil von der Menge an Code und dessen Komplexität, d.h. dem Aufwand diesen zu schreiben, abhängig. Im Folgenden wird zunächst die Menge betrachtet.
| Use-Case | Nativ SLOC Android + iOS | KMP SLOC Android + iOS + Geteilt | Einsparung durch KMP |
|---|---|---|---|
| UC1: Web | 297 | 273 | 8,08% |
| UC2: Datenbank | 635 | 669 | -5,35% |
| UC3: Schlüssel-Wert Speicher | 138 | 116 | 15,94% |
| UC4: Nebenläufigkeit | 252 | 265 | -5,16% |
| UC5: Medien und Hardware | 345 | 345 | 0% |
| UC6: Logik | 465 | 306 | 34,19% |
| Insgesamt (UC1 – UC6) | 2132 | 1974 | 7,41% |
Tabelle 5 – Vergleich der Menge an Code der Use-Cases
Tabelle 5 stellt die native Entwicklung (Nativ) und Kotlin Multiplatform (KMP) gegenüber. Sie zeigt für jeden Use-Case in der App die Menge an Code, die für dessen Implementierung benötigt wird. Betrachtet wird die Anzahl an Codezeilen, bereinigt von Kommentaren und Leerzeilen (SLOC). Zur Ermittlung der Werte wurde das Open-Source Programm tokei (Power, o.J.) eingesetzt. Der Code ist in allen Projekten gleich formatiert, entsprechend des offiziellen Standards von Kotlin bzw. Swift, sodass ein aussagekräftiger Vergleich möglich ist. Die Tabelle zeigt außerdem, wie viel Quellcode prozentual gegenüber der nativen Entwicklung eingespart wird. Je größer diese Einsparung ist, desto eher lohnt sich der Einsatz der Technologie für einen Use-Case. Die ermittelten Ergebnisse sind stark vom jeweiligen Anwendungsfall abhängig.
Die Logik von Netzwerkanfragen mit HTTP kann plattformübergreifend verwendet werden (UC1). Die Implementierung basiert auf der Library Ktor, einem verbreiteten Web-Client für Kotlin. Die Einsparung an Code ist mit 8% relativ gering.
Die persistente Speicherung von Daten in einer Datenbank (UC2) benötigt mehr Code als in der nativen Entwicklung. Dies ist auf unterschiedliche Vorgehensweisen zurückzuführen. In dem Kotlin Multiplatform Projekt wird SQLDelight eingesetzt, um typensichere Kotlin APIs aus SQL Statements zu erstellen. Durch Datenbanktreiber für Android und iOS können diese mit den jeweiligen SQLite Datenbanken der Plattformen verwendet werden. Dieselbe Strategie lässt sich auch in der nativen Entwicklung einsetzen, in diesem Fall würde Kotlin Multiplatform Quellcode einsparen. Jedoch bieten die nativen SDKs von Android und iOS Objektrelationale Abbildungen bzw. Abstraktionen wie Room und CoreData an. Ihren Einsatz reduziert den Aufwand signifikant. Schlüssel-Wert Paare (UC3) werden in Android mit den SharedPreferences und in iOS mit den UserDefaults gespeichert. Kotlin Multiplatform bietet einen Vorteil, wenn eine Library wie Multiplatform-Settings beide APIs zusammenfasst. Nebenläufigkeit (UC4) ist in Kotlin Multiplatform aufwendig zu implementieren. Obwohl die Klassen Fibonacci, Timer und WorkHelper geteilt werden, ist letztendlich der gesamte
Code in Kotlin Multiplattform länger als in der nativen Entwicklung. Kotlin/Native verfolgt ein Nebenläufigkeitsmodell das nicht direkt zu den Sprachen Kotlin und Swift kompatibel ist. Die Verwendung der entsprechenden API ist komplex und kaum dokumentiert. Eine Alternative ist z.B. die Library Coroutines von JetBrains, sie unterstützt in Kotlin/Native zurzeit jedoch nur den Thread, der die Benutzeroberfläche enthält (UI-Thread). Die Verwendung der Kamera und des Foto-Albums (UC5) ist auf Android und iOS verschieden. Die Zugriffsrechte werden unterschiedlich abgefragt. Android startet die Kamera mit einem Intent, in iOS wird der entsprechende ViewController instanziiert und angezeigt. Während in Android eine URL übergeben wird, die auf das Bild zeigt, gibt der ViewController in iOS das Bild als Objekt zurück. Das Teilen von Code ist nicht möglich und auch nicht sinnvoll. Dies trifft generell auf gerätespezifische Hardware (z.B. GPS, Neigungssensor) und APIs (Kontakte, Bilder, Videos) zu.
Der Use-Case Logik (UC6) belegt, dass sich Code, der keine nativen SDKs benötigt, vollständig teilen lässt. Die Klasse Game für das Spiel Tic Tac Toe kann einmal erstellt und von beiden Plattformen aus verwendet werden. Es wird ein Drittel weniger Code benötigt.
Die Navigation zwischen diesen Use-Cases kann, bedingt durch die Projektstruktur, aktuell nicht plattformübergreifend umgesetzt werden, da der native Code den plattformübergreifenden Code einbindet und nicht umgekehrt. Die Activities bzw. Storyboards sind dadurch im Multiplatform Code nicht bekannt.
Im Folgenden wird näher analysiert, wie komplex die Programmierung ist. Der Code liegt durch expect/actual in verschiedenen Ordnern und getrennt von der eigentlichen App. Die Entwicklung von Quellcode in „iosMain“ setzt viel Wissen über die Funktionsweise von Kotlin/Native voraus. Kotlin/Native ist nur zu Objective-C kompatibel, aber nicht direkt zu Swift. Es kann trotzdem auf den Teil der Swift-API zugegriffen werden, der mit @objc zu Objective-C exportiert wurde (JetBrains, o.J.f, Abschnitt Usage). In der Praxis bedeutet dies, dass z.B. die Klassen NSDate (Objective-C) und UIViewController (Swift mit @objc) in „iosMain“ verwendet werden können, die Klasse Date (Swift ohne @objc) jedoch nicht. Es existiert ein Mapping zwischen den Datentypen der verschiedenen Sprachen. Grundsätzlich müssen die Besonderheiten von Objective-C bekannt sein, obwohl der Code in „iosMain“ in
Kotlin entwickelt wird. Objective-C verwendet z.B. Zeiger und der Arbeitsspeicher wird manuell verwaltet. Dies sind Konzepte die in der Programmiersprache Kotlin normalerweise nicht existieren, sodass Kotlin/Native dafür spezielle Methoden wie z.B. „alloc“ oder „memScoped“ bereitstellen muss. Objective-C unterstützt sogenannte leichtgewichtige generische Datentypen. Sie können innerhalb von Objective-C verwendet werden, um Typeninformationen für Collections wie NSArray, NSDictionary oder NSSet anzugeben (Apple, 2015, Folie 68ff). Beim Importieren von Objective-C Klassen in Swift, bleiben diese Typeninformationen erhalten, dies funktioniert jedoch nur bei Collections (Apple, o.J.). Enthält der Multiplattform Code generische Datentypen in anderen Situationen, gehen die Typeninformationen verloren und es muss aufwendig manuell umgewandelt werden. Zusammengefasst kann Kotlin Multiplatform die Menge an Code in einigen Situationen gegenüber der nativen Entwicklung reduzieren. Dabei ist zu beachten, dass z.B. halb so viel Code nicht die Hälfte an Aufwand bedeutet, da Multiplatform anspruchsvoller in der Entwicklung ist. Je mehr Business-Logik ein Projekt enthält, desto eher lohnt sich der Einsatz von Kotlin Multiplatform.
Die Lesbarkeit von Quellcode wird in erster Linie von der verwendeten Programmiersprache bestimmt. Kotlin Multiplattform und die native Entwicklung greifen mit Java, Kotlin, Swift und Objective-C auf dieselben Sprachen zurück, daher ist die Lesbarkeit grundsätzlich vergleichbar. Kotlin Multiplatform führt ergänzend das Sprachkonstrukt expect/actual ein, dass große Gemeinsamkeiten mit Kotlin Interfaces bzw. Swift Protocols hat und daher genauso leserlich ist. Unterschiedlich ist die Strukturierung des Quellcodes. Zusammengehörige Bereiche sind in Kotlin Multiplatform stärker im Projekt verteilt, wodurch die Übersicht verschlechtert wird. Eine Rolle spielt auch die in Abschnitt 5.4.1 beschriebene größerer Komplexität des plattformübergreifenden Codes, der entsprechend schwerer zu verstehen ist.
Insgesamt kann Kotlin Multiplatform nicht ganz an die Lesbarkeit der nativen Entwicklung herankommen.
In einem Kotlin Multiplattform Projekt muss folgende Unterscheidung gemacht werden: Plattformspezifische Codebereiche, wie die Benutzeroberfläche, werden äquivalent zu normalen nativen Apps entwickelt, entsprechend existiert hier kein Unterschied bezüglich der Wartbarkeit. Plattformübergreifende Funktionalitäten sind nur einmal als geteilter Code implementiert. Muss hier ein Fehler korrigiert bzw. eine neue Funktion hinzugefügt werden, sind nur Anpassungen an einer Stelle und nicht in zwei separaten Apps notwendig. Die Wartung von Code ist in diesen Bereichen deutlich weniger Aufwand wie bei der reinen nativen Entwicklung.
Abbildung 7 – Anteil des geteilten Quellcodes im Kotlin Multiplatform Projekt der Use-Case App
Abbildung 7 stellt gegenüber, wie viel Prozent des Quellcodes im Kotlin Multiplatform Projekt geteilt ist (d.h. sich im Paket "Geteilt" befindet) und veranschaulicht somit ebenfalls, bei welchem Use-Case die Wartbarkeit am stärksten verbessert wird. Es zeigt sich, dass die Wartbarkeit vor allem bei Business-Logik (UC6) und HTTP-Anfragen (UC1) sehr gut ist. Auch bei der Nebenläufigkeit (UC4) und Datenbankoperationen (UC2) wird die Wartbarkeit bemerkbar verbessert. Da jeder Use-Case eine Benutzeroberfläche enthält und diese nicht geteilt werden kann, ist der Anteil des gemeinsam genutzten Codes nie 100%. Zu beachten ist außerdem, dass die Use-Cases UC2 und UC4 mit Kotlin Multiplatform mehr Code benötigen, als mit der nativen Entwicklung.
Das Schreiben von Unit-Tests ermöglicht es, einzelne Funktionalitäten auf Korrektheit zu prüfen. In einem Kotlin Multiplatform Projekt kann der native Android und iOS Code mit denselben Frameworks und Tools getestet werden, die auch sonst bei der nativen Entwicklung Verwendung finden. Das Testen des plattformübergreifenden Codes im Projekt ist ebenfalls möglich. Kotlin bietet dazu mit „kotlin.test“ eine API an, die als Abstraktion über Test-Frameworks dient. Es sind grundlegende Annotationen (@Test, @BeforeTest, @AfterTest) und Funktionen (assert, assertEquals, assertFails, usw) enthalten.
Jeder Test muss für jede Plattform ausgeführt werden, da durch expect/actual das Verhalten unterschiedlich sein kann. Dafür wird jeweils das plattformspezifische Test-Framework aufgerufen. Bei Android ist dies JUnit, bei iOS wird ein Simulator gestartet und der Test darauf ausgeführt. Mit mockk21 existiert ein kompatibles Mocking-Framework. Eine Unterstützung durch die Entwicklungsumgebung fehlt zurzeit. Tests werden in Android Studio nicht als solche erkannt und können nur über das Terminal mit Gradle gestartet werden.
Grundsätzlich ist das Testen von Kotlin Multiplatform Projekten möglich, aber die aktuelle Unterstützung der IDE nicht ausreichend. Ein großer Vorteil im Vergleich zur nativen Entwicklung ist, dass durch den plattformübergreifenden Code die Anzahl an Tests, die geschrieben werden müssen, reduziert wird.
Kotlin Multiplatform macht keine Vorgaben bezüglich der zu verwenden Architektur, daher ist sowohl MVP als auch MVVM einsetzbar. Werden in einem Projekt nur einzelne Klassen geteilt, kann die Architektur der Android und iOS Anwendung ohne Probleme voneinander abweichen. In Projekten, die einen Großteil der Business-Logik gemeinsam verwenden, also auch die Presenter bzw. ViewModel teilen, müssen jedoch beide Plattformen dieselbe Architektur einsetzen. Dies bedeutet für die Firma appcom interactive, dass entweder Android oder iOS Entwickler auf ihre gewohnten Vorgehensweisen sowie Erfahrungen verzichten müssen und die Produktivität kurzfristig sinkt. Darüber hinaus sollte bei der Konzeption der
Anwendung beachtet werden, dass sich in iOS aktuell nur ein mit Kotlin Multiplatform erstelltes Framework gleichzeitig einbinden lässt. Jedes Apple-Framework enthält spezielle Klassen zur Kompatibilität zwischen Kotlin und Objective-C, z.B. KotlinInt, KotlinLong, KotlinFloat, die andernfalls vermutlich aufgrund desselben Namens kollidieren (JetBrains, o.J.f). Die geteilte Logik einer App kann daher zurzeit nicht weiter modularisiert werden.
Die Entwicklung mit Kotlin Multiplattform setzt umfassendes Wissen in verschiedenen Themengebieten voraus. Ein Multiplatform Projekt enthält zwei native Apps. Kenntnisse in der Android-Entwicklung mit Kotlin und in der iOS-Entwicklung mit Swift sowie Objective-C sind unbedingt notwendig. Der von beiden Apps gemeinsam verwendete Code ist in der Sprache Kotlin geschrieben, aber auch für diesen wird grundlegendes Wissen zu den Plattformen benötigt.
Listing 2 – Gegenüberstellung der Syntax von Kotlin und Swift. Der Programmausschnitt zählt die Buchstaben in dem String „Hello World“
Es existieren jedoch viele Faktoren, die den Einstieg für Entwickler erleichtern. Kotlin und Swift sind unterschiedliche Programmiersprachen, die Syntax und viele Konzepte sind trotzdem ähnlich. Beherrscht ein Entwickler eine der Sprachen, kann er die andere zumindest verstehen und selbst kleinere Änderungen an bestehendem Code vornehmen. Listing 2 zeigt dazu ein Codebeispiel in beiden Sprachen, Unterschiede in der Syntax sind grau markiert. Des Weiteren werden die benötigten Programme zu einem großen Teil bereits in der nativen Entwicklung eingesetzt, sodass auf bestehende Kenntnisse aufgebaut werden kann. IOS-Entwickler haben hier einen größeren Aufwand, da sie auf Android Studio angewiesen sind, um am geteilten Code mitarbeiten zu können. Anders herum müssen Android Entwickler Xcode jedoch nicht verwenden.
Eine Person muss grundsätzlich nicht alleine über das gesamte beschriebene Wissen verfügen, je nachdem wie die Teamstrukturen bzw. Arbeitsweisen gewählt wurde (siehe 5.5.2). Dadurch ist der Einstieg in Kotlin Multiplattform für erfahrene App-Entwickler mit angemessenem Aufwand möglich.
Die eingesetzte Technologie hat Einfluss auf die Arbeitsweise und Koordination im Team. In Kotlin Multiplatform Projekten ist immer nativer Code enthalten, deshalb werden Android und iOS Entwickler zwingend benötigt. Es sind zwei Szenarien denkbar, wie diese plattformübergreifenden Funktionalitäten implementieren.
- Der geteilte Code wird nur von Android Entwicklern erstellt, da diese bereits Erfahrung in Kotlin sowie mit Gradle und Android Studio besitzen. Fehlendes Wissen, z.B. für die Implementierung von „iosMain“, eignen sie sich bei Bedarf an. Ein Problem ist, dass iOS-Entwickler nicht eigenständig Änderungen am geteilten Code vornehmen können. Diese Abhängigkeit ist vor allem dann kritisch, wenn die Entwicklungsgeschwindigkeiten verschieden sind.
- Der geteilte Code wird von iOS und Android Entwicklern gemeinsam erstellt. Sinnvoll sind hier Maßnahmen wie Pair-Programming, gegenseitige Code-Reviews oder Pull-Requests, um die Besonderheiten der jeweils anderen Plattform mit der Zeit kennenzulernen. Personen im Team können flexibler eingesetzt werden und eigenständig Änderungen am geteilten Code vornehmen. Dies setzt voraus, dass Entwickler die verwendeten Sprachen, das Tooling und die SDKs beider Betriebssysteme grundlegend beherrschen.
Beide Szenarien sind grundsätzlich in der Firma appcom interactive umsetzbar und stehen nicht im Konflikt mit der Arbeitsweise im Unternehmen, denn ein Scrum-Team für die Entwicklung nativer Apps enthält unter anderem Android-Entwickler und iOS-Entwickler. Letztendlich handelt es sich nur um theoretische Konzepte, wie die Arbeit mit Kotlin Multiplatform aussehen könnte. Die native Entwicklung hat im Vergleich den großen Vorteil, dass sie seit Jahren eingesetzt wird, die Risiken bekannt und Abläufe optimiert sind.
Die offizielle Dokumentation des Herstellers JetBrians beschränkt sich aktuell auf eine kurze Beschreibung der grundlegenden Funktionsweise, ein Tutorial, das die Erstellung einer Hello-World App erklärt, sowie zwei komplexere Beispielanwendungen auf GitHub. Regelmäßig finden Veranstaltungen statt, z.B. die jährliche Konferenz „Kotlin Konf“, auf denen die Technologie beworben und in Vorträgen näher gezeigt wird.
Literatur in Form von Büchern ist kaum zu finden, Ebel (2019) stellt die Technologie zumindest kurz vor. Als Informationsquelle dienen hauptsächlich Blogbeiträge, soziale Netzwerke sowie Treffen, auf denen andere Entwickler ihre aktuellen Erfahrungen teilen. Die existierende Community ist im Vergleich zu anderen Technologien sehr klein. In dem Forum Stack Overflow finden sich zum Beispiel nur 172 Fragen zu Kotlin Multiplatform (Kotlin: 32334 Fragen, Java: 1620503 Fragen). Auf der Plattform Medium wurden im Jahr 2019 insgesamt 45 Artikel zu Kotlin Multiplatform veröffentlicht (Kotlin: 254 allein im Monat Dezember 2019, Java: 621 allein im Monat Dezember 2019). Auch im offiziellen Kotlin Forum ist der Anteil von Kotlin Multiplatform mit 47 Diskussionen nicht groß (Android: 512 Diskussionen, Libraries: 261 Diskussionen). Es existieren bereits eine Vielzahl an Libraries, die unterschiedliche Themengebiete wie beispielsweise Netzwerk, Speicher, Dependency Injection, Dateien oder Logging abdecken, eine Übersicht gibt Aratani (2019).
Insgesamt ist die Dokumentation lückenhaft und nicht ausreichend sowie die Unterstützung durch andere Entwickler im Vergleich zur nativen Entwicklung eher gering. Des Weiteren sollte beachtet werden, dass der Hersteller sowie kooperierende Firmen Interesse daran haben, andere für die Kotlin Multiplatform zu begeistern. Bei Vorträgen stellt sich die Frage, wie objektiv die eigene Technologie dargestellt wird.