Warum wir Ihre App mit Kotlin Multiplatform entwickeln

Wir von dreipol werden häufig nach den Beweggründen für die Wahl einer spezifischen Entwicklungstechnologie für unsere Mobile Apps gefragt. Warum wir bis jetzt noch keine Flutter-App offeriert haben oder auf eine andere Crossplatform-Lösung setzen, führe ich in diesem Beitrag aus.

Julia Strasser
dreipol

--

Die meisten Apps sollen heute sowohl im Google Play Store als auch Apple App Store zu finden sein. Auf dem Weg dorthin begegnen wir im Rahmen unserer Offertstellung in der Regel zwei Umsetzungsmöglichkeiten: der nativen Entwicklung für iOS und Android oder der Verwendung einer Crossplatform-Lösung.

Die beiden Optionen skizziere ich kurz auf, bevor ich danach auf die Gründe eingehen möchte, weshalb wir bei dreipol nun bereits seit mehreren Jahren auf die native Entwicklung mit Kotlin Multiplatform setzen.

Native App-Entwicklung

In zwei Programmiersprachen (meistens von zwei Entwickler:innen umgesetzt) werden zwei voneinander losgelöste Apps erstellt, d.h. je eine App für Android und iOS.

Die Programmiersprache Kotlin wird dabei für Android Apps verwendet, Swift für iOS Apps. Dies hat zur Folge, dass sämtliche Logiken wie Server- und Datenbank-Abfragen in der jeweiligen Programmiersprache für jede Plattform zweimal umgesetzt werden müssen. Der doppelte Aufwand zeigt sich ohne Überraschung im Preis und die native Entwicklung kann trotz einiger Vorteile (welche Sie weiter unten erfahren) nicht mit dem geringeren Aufwand der Crossplatform-Entwicklung konkurrieren.

Crossplatform App-Entwicklung

In einer Programmiersprache wird eine App entwickelt, die für Android und iOS herausgegeben wird. Je nach Bedarf können auch spezifische Komponenten nur für die eine Plattform angepasst werden.

Flutter ist eine solche Crossplatform-Lösung. Von Google auf den Markt gebracht, basiert sie auf der Programmiersprache Dart. Was sich nicht direkt auf den ersten Blick zeigt: der Aufbau unter der «Oberfläche». Nutzer:innen nehmen Crossplatform Apps auf der jeweiligen Plattform so wahr, als wären sie mit deren Komponenten gebaut worden. In Wirklichkeit allerdings handelt es sich um eigene Komponenten. Beispiel: Ein Button in einer Crossplatform App baut nicht auf einem Android- bzw. iOS-Button auf. Technisch bedeutet dies eine zusätzliche «Schicht» innerhalb des User Interfaces, da die Entwickler:innen nicht direkt mit den plattformspezifischen Komponenten arbeiten.
Der grosse Vorteil für Kund:innen, den Entwicklungsumfang nur einmal bezahlen zu müssen, ist bei dieser Lösung nicht zu übersehen.

Neben der nativen und Crossplatform-Entwicklung bieten sogenannte Progressive Web Apps (PWA) eine weitere Möglichkeit in der Technologiewahl. Deren Vor- und Nachteile müssten jedoch aufgeschlüsselt nach App-Anforderungen separat analysiert werden – das machen wir vielleicht in einem künftigen Blog-Beitrag. :)

Unsere Gründe für die native App-Entwicklung

Wir wissen nicht, was die App-Zukunft bringen wird, allerdings gab es in den letzten Jahren immer wieder Crossplatform-Lösungen, die kamen und leider auch wieder verschwanden.

Bei dreipol setzen wir seit jeher auf die native App-Entwicklung, damit wir unseren Kund:innen langjährige Apps mit der besten User Experience anbieten können.

Langlebigkeit und Flexibilität

Die grossen App-Anbieter stellten uns Entwickler:innen in der Vergangenheit immer wieder neue Anforderungen und Richtlinien auf, boten uns aber stets auch wieder neue Möglichkeiten. Unsere native Lösung erlaubt(e) es, flexibel darauf zu reagieren und auch unsere bestehenden Apps über diese vielen Jahre hinweg weiterzuentwickeln und um diese Neuerungen zu erweitern. Komplette Neuentwicklungen waren dabei nicht nötig und wir konnten die Wartungskosten stets klein halten.

Die jeweiligen Anbieter sind langlebig und sie werden uns weiterhin Möglichkeiten zur Verfügung stellen, um die Apps zu aktualisieren und zu erweitern. Bei Crossplatform-Lösungen besteht hingegen eine Abhängigkeit von Drittanbieter:innen.

Keine Abstriche bei der User Experience

Wir stellten immer wieder Mängel in der User Experience von Crossplatform Apps fest. Vor allem bei vielen Interaktionen der Nutzer:innen, z.B. via Texteingaben oder Auswahlfeldern, ist die Benutzerführung teilweise holprig. Die Überlappung von relevanten Informationen durch das Einblenden der Tastatur oder fehlendes haptisches oder visuelles Feedback beim Berühren des Bildschirms illustrieren diese Problematik gut. Wir setzen deshalb auf native Elemente für ein optimales Benutzererlebnis. Aus meiner Sicht auch mit ein Grund, weshalb die grössten Chat-Apps auf native App-Entwicklung setzen und damit erfolgreich sind — welche:r Nutzer:in würde nicht die App wechseln, wenn die sich tägliche Interaktion damit mühsam anfühlt?

Mir ist es wichtig zu betonen, dass dieser Abschnitt nicht aussagen soll, dass eine Crossplatform-Lösung keine oder gar die falsche Wahl ist. Im Gegenteil: Gerade um mittels Prototyp erste User-Rückmeldungen zu erhalten, kann dies eine preiswerte Option sein. Für längerfristige Projekte empfehlen wir Crossplatform-Lösungen aber auch heute noch nicht.

Was raten wir von dreipol unseren Kund:innen also? Unser Favorit ist Kotlin Multiplatform; eine auf nativer Entwicklung basierende Umsetzungstechnologie von JetBrains. Kotlin Multiplatform kombiniert die Vorteile der nativen App-Entwicklung mit jenen der Crossplatform-Entwicklung.

Das Beste aus zwei Welten: Kotlin Multiplatform

Kotlin Multiplatform erlaubt es uns, die Business-Logik von Android und iOS Apps zu teilen. Das heisst, der Code muss nur einmalig entwickelt und kann zentral gepflegt werden. Dazu gehören beispielsweise Datenbank- und Server-Abfragen. Deren Umsetzung wird nur einmal geschrieben und von beiden Apps gleichermassen verwendet.

Im Vergleich zu herkömmlichen Crossplatform-Lösungen werden mit Kotlin Multiplatform allerdings User-Interface-Elemente native entwickelt. Damit erzielen wir die beste User Experience für die Nutzer:innen unserer Apps. Das heisst, Komponenten, welche die Nutzer:innen in einer App sehen, sind native Elemente von Android oder iOS. Der Aufwand der «doppelten» Entwicklung für diese Elemente wird für beide Plattformen um den Willen des bestmöglichen Benutzererlebnisses in Kauf genommen.

Wie geht es weiter?

Kotlin Multiplatform befand sich lange im Alpha- und Beta-Stadium. Seit November 2023 ist es aber endlich «stable and production-ready».

Bei dreipol konnten wir bereits einige Apps mit dieser Technologie umsetzen und wertvolle Erfahrungen sammeln. Dank unserer neuen Architektur (Details dazu im Blog-Post von Kai) werden wir mit jedem Projekt noch effizienter. Auch wir in der Entwicklung profitieren von der geteilten Business-Logik und der sauberen Architektur. Ein Beispiel ist unsere Entsorgungs-App reCHycle (Download: iOS, Android). Details dazu finden sich im Showcase auf Open-Data der Stadt Zürich.

Die Idee der geteilten Business-Logik, ohne sich von einer spezifischen UI-Komponente zu lösen, kann bei Kotlin Multiplatform auch auf andere Plattformen erweitert werden. Bereits heute gibt es z.B. Ansätze, Kotlin Multiplatform für Webseiten zu verwenden. Eine spannende und vielversprechende Option für Produkte, welche Logiken zwischen einer Webseite und Apps teilen möchten.

Auch wenn wir nicht in die Glaskugel schauen können: Kotlin Multiplatform wurde bisher stetig weiterentwickelt und erfreut sich in der Dev Community immer grösserer Beliebtheit; sprich mehr und mehr Entwickler:innen arbeiten damit und erweitern die Tools. Ein weiterer Grund für uns, bei dreipol auf diesen Ansatz der geteilten Business-Logik zu setzen.

Wie können wir Sie unterstützen?

Stehen Sie vor einer Technologie-Entscheidung und möchten die Möglichkeiten spiegeln? Meine Kolleg:innen und ich stehen Ihnen gerne zur Verfügung und freuen uns auf anregende Diskussionen und Gespräche.

Vielen Dank fürs Liken und Teilen!

Nichts mehr verpassen? Abonnieren Sie unseren Newsletter, folgen Sie uns auf LinkedIn, oder besuchen Sie unsere Webseite.

--

--