19.01.2022

Eine Codebasis für alle Plattformen: mit Webtechnologien zur eigenen iOS-App

Eine mobile App im App-Store zu platzieren, bedeutet meist einen Umgang mit nativen Tools, verschiedenen Frameworks und unterschiedlichen Programmiersprachen je nach Betriebssystem. Zum Entwickeln von Apps im iOS-Betriebssystem wird Swift oder Objective-C genutzt, bei Android eher Java oder Kotlin. Der Aufwand in beiden App-Stores vertreten zu sein erhöht sich dadurch, dass die Programmierung für die beiden Betriebssysteme sehr unterschiedlich ist. So muss eine App zeitintensiv und kostspielig doppelt entwickelt werden. Mit der reinen Entwicklung der App ist das Thema jedoch nicht abgeschlossen. Folgekosten durch Wartung und Verbesserungen müssen berücksichtigt werden. Infolgedessen haben wir uns intensiver mit der Cross-Plattform-Entwicklung beschäftigt. Die Idee dahinter ist simpel: es wird eine App entwickelt, die auf mehreren Plattformen gleichzeitig und damit im Idealfall auf iOS und Android läuft. Hierbei lässt sich zwischen nativer Cross-Plattform-Entwicklung und hybrider Cross-Plattform-Entwicklung unterscheiden. Native Cross-Plattform-Entwicklung kann beispielsweise in React Native mit JavaScript oder Flutter mit Dart erfolgen. Nach der Entwicklung kann die App dann einmalig in z.B. eine iOS App umgewandelt werden. Den hybriden Ansatz haben wir uns herausgepickt und praktisch angewandt. Die vollständige Umsetzung haben wir auch bei der Digitalen Woche Dortmund 2021 in unserem Workshop “Eine Codebasis für alle Plattformen - Mit Webtechnologien zur eigenen iOS App” vorgestellt.

Capacitor als Grundlage

Das Capacitor-Projekt stammt aus dem Hause Ionic und bildet den Nachfolger zu einem ähnlichen Projekt namens Cordova. Hierbei entwickelt man selbst eine Web-App und das Capacitor-Projekt kombiniert diese dann mit einer Run-Time, um die Web-App sowohl auf iOS als auch eine Android als App auszuführen. Das Capacitor-Projekt bildet die Run-Time und kümmert sich darum, dass die Ausführung auf allen Plattformen funktioniert. Durch den Einsatz einer Web-App kann auf bereits vorhandene Entwicklung zugegriffen werden. Der Vorteil liegt klar auf der Hand: es muss bei der Entwicklung nicht bei null gestartet werden. Somit ermöglicht das Capacitor-Projekt eine App zu bauen, die sich im Endeffekt verhält wie ein Browser. Man startet eine App, die eine Web-App in einem Browserfenster anzeigt. Die gesamte App läuft in diesem Browserfenster und kann alle Dinge und UI-Tools anzeigen, die gewünscht sind. Zudem stellt Capacitor durch Plugins die Funktion bereit, auf Funktionalitäten des jeweiligen Betriebssystems zuzugreifen, z.B. Push Notifications, Geolocation, Motions Sensors, etc. Neben den Open-Source-Plugin von Capacitor selbst, gibt es zusätzliche Plugins aus der Community und die Möglichkeit, selbst Plugins zu entwickeln.

Vorteile der Umsetzung

Das Aussehen und das Verhalten einer App auf einem bestimmten Betriebssystem ist für Nutzer manchmal schwierig in Worte zu fassen oder konkret zu beschreiben. Trotzdem wissen die Nutzer, wie eine iOS oder Android App aussieht. Kleine Veränderungen im Look & Feel können hier große Auswirkungen auf die Nutzerzufriedenheit haben.

Das Layout und Aussehen der App darf deshalb nicht vernachlässigt werden. Natürlich besteht die Möglichkeit, die App selbst nach allen CSS-Vorlieben zu stylen und aufzubereiten. Darüber hinaus stellt Capacitor zusätzlich eine umfassende UI-Bibliothek von Ionic mit verschiedenen fertig designten Elementen für iOS und Android zur Verfügung.

Wie kommt die App nun in den App-Store?

An Apple führt kein Weg vorbei. Um die App bei Endkunden auf den mobilen Geräten platzieren zu können, muss die App in den App-Store gebracht werden. Um das zu erreichen, liegt eine erste Grundvoraussetzung in der kostenpflichtigen Mitgliedschaft im Apple Developer Program. Hier wird ein Lizenzvertrag zwischen Apple und dem Entwickler geschlossen, damit Apple erlaubt, Apps in den App-Store einzustellen. Erst nach Vertragsabschluss bietet Apple Zugriff auf ein Programm namens App Store Connect. Hier lassen sich die eigens programmierten Apps hochladen und verwalten, also eine Art CMS-System für den App-Store. Es lassen sich z.B. Information wie der App-Name oder das App-Icon aus App Store Connect anlegen und pflegen. Eine weitere Funktionalität nennt sich TestFlight und bezeichnet ein Programm, das ermöglicht, die hochgeladene App mit einem ausgewählten Publikum an Testpersonen zu teilen. Über das TestFlight-Programm können die Tester auch schließlich Rückmeldung zur App geben. Ist die Testphase abgeschlossen vollendet die Einreichung bei Apple den Vorgang. Allerdings schaltet Apple die App nicht sofort live in den App-Store, sondern behält sich das Recht vor, nochmals zu überprüfen, ob der Entwickler alle Guidelines seitens Apple eingehalten und umgesetzt hat. Sobald diese Review durch ist, kann die App endlich durch den Endnutzer aus dem App-Store heruntergeladen werden.

Lessons learned

Viele der vorgestellten Projekte sind kostenfrei als Open Source von Ionic zur Verfügung gestellt. Vor allem im CI/CD Prozess muss aber mit Kosten gerechnet werden, wenn man das Vertesten seiner App nicht manuell selbst übernehmen muss. Ionic bietet hier ein kostenpflichtiges Produkt namens AppFlow an, das automatisiert die App vertestet. Capacitor bietet eine elegante Lösung für Apps auf iOS und Android. Wofür noch keine Lösung bereitsteht, sind Applikationen für WatchOS und WearOS, also Apps für Smartwatches. Trotzdem bietet das Capacitor-Projekt eine schnelle und kostengünstigere Lösung im Vergleich zur reinen nativen Entwicklung. Die App kann mit deutlich weniger Zeitaufwand den ersten Testern, Kunden oder Partnern präsentiert werden. Allerdings ist der zeitliche Aufwand des gesamten Prozesses von Lizenzvertrag bis Livegang der App nicht zu unterschätzen. In unserer Praxis hat sich gezeigt, dass man für diesen Vorgang lieber etwas mehr als zu wenig Zeit einplanen sollte. Es müssen viele Sicherheitsaspekte seitens Apple beachtet werden, die weiterhin Koordinations- und Zeitaufwand kosten. Außerdem muss man sich bewusst sein, dass die Kraft auf Seiten von Apple liegt, sie entscheiden schlussendlich darüber, ob die App in den App-Store kommt oder nicht. Zu Beginn des Entwicklungsprozesses zu überlegen, ob die App Erfolgschancen hat und ob man die Apple Guidelines abnickt, ist daher fast unumgänglich.

Im Rahmen unseres Workshops bei der Digitalen Woche 2021 hatten wir die Möglichkeit, uns mit Entwicklern über andere Ansätze zur Cross-Plattform-Entwicklung auszutauschen. Das hat uns nochmals in der Entscheidung für das Capacitor-Projekt bestärkt. Wir freuen uns, mit dem Capacitor-Projekt weiterhin schnell und effizient gute Apps mit unseren Kunden und Partnern zu entwickeln!

Jan Sauer

Softwareentwickler

Zurück zum Blog
Mehr Blogartikel...
Unser Blog behandelt eine Vielzahl verschiedener Themen. Wir setzen uns in unseren Artikeln mit Gedanken, Erfahrungen und Meinungen zu Ereignissen und technischen Neuerungen auseinander, die uns im Arbeitsalltag begegnen.

Mehr Blogartikel...

Warum das Log4J Desaster vorhersehbar war
Dass eine Lücke wie bei Log4J früher oder später auftreten würde, war vorhersehbar. Dabei hätten wir vieles vermeiden können, wenn wir uns nur an etablierte Best-Practice halten.
Jörg Herbst | 14.12.2021

Warum das Log4J Desaster vorhersehbar war

Wie und womit wir arbeiten
A fool with a tool is still a fool. Das gilt natürlich auch für Software. Trotzdem können die richtigen Werkzeuge ungeheuer hilfreich sein, um die Probleme einer Software-Agentur zu lösen.
Jörg Herbst | 2.02.2022

Wie und womit wir arbeiten