Vorteile von Kotlin für die Businesslogik von Android- und iOS-Apps

Unternehmen entscheiden sich oft für die Entwicklung einer App auf den mobilen Plattformen Android und iOS, weil sie damit die Bedürfnisse der User auf dem Smartphone besser berücksichtigen können. Native Plattform-Features, wie etwa Push-Notifications oder die reibungslose Integration von Google- oder Apple-Pay, können das Nutzererlebnis deutlich erhöhen und darüber hinaus einen Einfluss auf die Kundenbindung und den Erfolg einer App haben.

User haben heutzutage eine hohe Erwartungshaltung an die Benutzeroberfläche, denn diese hilft ihnen dabei, sich auch in einer neuen App rasch zurecht zu finden. Dazu zählt unter anderem die korrekte Navigation innerhalb der App sowie die Einhaltung der UI-Guidelines der jeweiligen Plattform. So fällt eine Android-App, die mit iOS-Guidelines erstellt wurde, meist negativ auf. Schon grundlegende Elemente wie der Zurück-Button oder das Menü sind je nach Betriebssystem anders und somit ungewohnt für User, die eigentlich das andere Betriebssystem gewohnt sind.

Entwickler-Communities helfen bei der Entwicklung von Native Apps

Eine Forderung von Konsumenten ist häufig ein anspruchsvolles Design mit Animationen und die Verwendung der neusten Plattformfeatures (etwa Darkmode). Und dies am liebsten ab dem Tag, an dem die neue OS-Version veröffentlicht wurde. Unternehmen, die Apps anbieten, müssen also schnell reagieren. Bei diesen Anforderungen führt oft kein Weg an einer nativen App vorbei. Native OS-Features - beispielweise der Zugriff auf den Fingerprintreader oder die Bluetooth-Schnittstelle - können zwar auch mit anderen Crossplattform-Lösungen genutzt werden, jedoch wird aber dann meist ein externes Plugin benötigt. Dieses stammt in der Regel nicht von Google oder Apple selbst und kann potentielle Fehler enthalten.

Auch Apple und Google sind nicht vor Bugs gefeit. Durch ihren hohen Testaufwand und die große Benutzerbasis fallen diese aber schnell auf und werden rasch beseitigt. Bei Drittanbietern von Plugins hingegen stellt sich die Frage, ob mögliche Fehler (zeitnah) behoben werden. Diese Unsicherheiten machen es schwer, ein anspruchsvolles Projekt zu starten. Denn mitten in der Entwicklung könnte es zu einem sehr großen oder sogar unlösbaren Problem kommen. Gerade das Verwenden der Bluetooth-Schnittstelle ist auch in der nativen Entwicklung teilweise nicht trivial. Aber durch eine große Community und lange Erfahrung in der nativen Entwicklung, gibt es im Internet zahlreiche Hilfestellungen. Cross-Plattform-Lösungen sind noch sehr jung und nicht weit verbreitet. Dies könnte dazu führen, dass es zu einem Problem keine Lösung gibt.

Die Vorteile der Kotlin-Multiplattform für Entwickler

Mit der Kotlin-Multiplattform ist es möglich, den Code der Businesslogik gemeinsam für iOS und Android zu verwenden und mit dem Rest in der entsprechenden nativen Welt zu bleiben. Bei beiden Plattformen wird der geteilte Code als Library eingepflegt. So können Entwicklerinnen und Entwickler weiterhin ihre bekannten Tools und Sprachen verwenden. Zudem kann weiter auf die nativen OS-Features zugegriffen werden. Ändert sich etwas in der Businesslogik, müssen die Developer nur ein Update der Library durchzuführen. Zudem ist es möglich, die Businesslogik schrittweise in eine geteilte Library zu migrieren.

UI und UX bleiben dadurch vollständig unter der Kontrolle der nativen Plattform und deren Developer, die schon Jahre an Erfahrung haben und entsprechend effizient damit umgehen können. Bei neuen Plattform-Features wie der Darkmode wird nur ein Update der UI benötigt - ohne Auswirkung auf die Businesslogik. Auch bei größeren Plattform-Updates, wie beispielsweise einer neuen Möglichkeit die UI zu entwickeln (SwiftUI / Jetpack Compose), gibt es keine Hindernisse diese zu verwenden.

Geteiltes Leid ist halbes Leid: Mit Kotlin Synergien bei der Entwicklung der Businesslogik schaffen

Durch das Teilen der Businesslogik muss diese nur einmal entwickelt werden. Dieses Versprechen von „Einmal entwickeln - läuft auf beiden Plattformen“ kennen wir schon. Leider war dieses Versprechen in der Vergangenheit kompromissbehaftet. Insbesondere bei der UI wurden immer wieder zeitintensive UI-/UX-Anpassungen für eine der Plattformen benötigt.

Beim Teilen der Businesslogik wird der Fokus nur auf die Businesslogik und die korrekte Implementation gelegt. Es wird daher sichergestellt, dass die Logik nach der einmaligen und korrekten Implementierung auf beiden Plattformen richtig ausgeführt wird. Gerade bei der Entwicklung einer Android- und iOS-App tritt es häufiger auf, dass es unterschiedliche Fehler in den Apps gibt. Hier kommt es vor, dass die Entwickelnden möglicherweise die Anforderungen unterschiedlich verstanden oder fehlerhaft implementiert haben.

Die Businesslogik, die zwischen den Plattformen geteilt werden soll, wird - mit zwei Ausnahmen -genau wie eine normale Kotlin-Bibliothek entwickelt. Die Ausnahmen bestehen beim Konfigurieren des Projekts und beim Verwenden von nativen Android- oder iOS-Features im geteilten Code. Beim Konfigurieren muss definiert werden, welche Plattformen unterstützt werden sollen. In unserem Fall wäre dies Android und iOS. Auf der offiziellen Kotlin-Multiplattform-Projektseite stehen allerdings zahlreiche Dokumentationen und Hilfen für die Konfiguration bereit. Aber keine Sorge, das Konfigurieren ist üblicherweise nur einmal beim Start des Projekts nötig.

Beim Verwenden von nativen Plattformfeatures – etwa der Logausgabe auf Android mit Hilfe von Logcat und auf iOS mit NSLog - spielen die zwei speziell dafür hinzugefügten Keywords expect und actual eine große Rolle. Damit ist es möglich, ähnlich wie bei einem Interface, Methodensignaturen zu definieren, die wiederrum nativ implementiert werden müssen. Somit können plattformspezifische Unterschiede auch in der geteilten Logik umgesetzt werden. Dies ist beispielsweise bei biometrischen Sensoren und GPS-Funktionen relevant, da hier größere Unterschiede zwischen den Plattformen existieren.

Unter der Haube: Libraries von Android und iOS

Beim Verwenden der Library unter Android gibt es die Möglichkeit, ein Android Archive (AAR) zu erstellen, das wie eine normale Abhängigkeit in ein Android-Projekt eingebunden werden kann. Alternativ kann auch der Code als Git-Submodule in ein Android-Projekt eingebunden werden. Beides bietet seine Vor- und Nachteile.

Für das Verwenden der Library in einem iOS-Projekt wird der Code mit Hilfe von LLVM in ein Framework kompiliert. Dadurch kann das entstandene Framework in Objectiv-C und Swift Projekten verwendet werden, wie auch andere Frameworks in ein Projekt eingebunden werden.

It’s all about the money – warum Crossplattform-Lösungen oft nicht halten, was sie versprechen

Legt sich ein Kunde bereits bei der Planung einer App auf eine klassische Crossplattform-Lösung fest, hat er meist die mögliche Kostenersparnis im Hinterkopf. Dafür gibt es sehr gute Argumente. Jedoch bleiben die kritischen Punkte häufig unerwähnt und es wird das Blaue vom Himmel versprochen. Eine Aussage wie "Eine Person entwickelt eine App für beide Plattformen in kürzester Zeit". Mag für kleinere Apps allenfalls stimmen, doch gerade bei größeren Projekten entwickelt sich die anfängliche Kostenersparnis zu einem Kostenfresser.

Soll die App auf beiden Plattformen gut aussehen, mit schönen Animationen und flüssigen Übergängen zwischen den einzelnen Screens, wird es bei den gängigen Crossplattform-Lösungen sehr schnell kompliziert. Die Developer brauchen ein großes Maß an Wissen über die jeweilige Plattform, um diese Anforderungen umsetzen zu können. Dadurch muss nicht nur Wissen über die Crossplattform-Lösung vorhanden sein, sondern auch über die beiden nativen Plattformen. Allein hiermit benötigt ein Developer vertieftes Wissen von drei Plattformen und muss dieses Wissen zudem aktuell halten. Für Android und iOS erscheint jährlich ein neues großes Software Update, das oft viele neue Funktionen anbietet.

Aber auch bei den Crossplattform-Lösungen dreht sich die Welt nicht langsamer als in der nativen Welt. Neue Lösungen kommen und gehen und je mehr Zeit verstreicht desto schwieriger wird es Entwicklerinnen und Entwickler dafür zu finden, da diese möglicherweise schon auf ein neues Pferd umgesprungen sind. Bei der nativen Entwicklung besteht dieses Problem nicht. Ein nativer Developer kommt mit älteren und neueren Apps zurecht und ist nicht selten ein Experte seiner Plattform. Er kann dabei nicht nur die Anforderungen umsetzen, sondern dem Unternehmen auch beratend zur Seite stehen, um das Maximum aus der Plattform rauszuholen.

Sharing is caring: Die Kotlin-Multiplattform sticht Crossplattform-Lösungen und Silo-Entwicklungen

Für uns gibt es keinen Weg mehr an der Kotlin-Multiplattform vorbei. Der Fokus, der auf das Teilen der Businesslogik gelegt wird, ist für uns ein klarer Vorteil gegenüber anderen Crossplattform-Lösungen sowie der Silo-Entwicklung (Android und iOS werden separat entwickelt, ohne Code oder Ähnliches zu teilen). Die Android- und iOS-Entwicklerinnen und -Entwickler haben beim Verwenden der Kotlin-Multiplattform große Freude, da sie ihre gewohnte Arbeitsweise kaum anpassen müssen. Auch ihr Wissen über die jeweilige Plattform kann weiterhin genutzt werden, um großartige Apps mit geschmeidigen Animationen, schönen Übergänge und zufriedenen Usern zu entwickeln.

Ihr möchtet mehr zu spannenden Themen aus der adesso-Welt erfahren? Dann werft einen Blick in unsere bisher erschienen Blog-Beiträge.