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.

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.