Mobile Entwickler

Der Ein oder Andere mag sich noch an das Blackberry, Windows Mobile oder gar Symbian auf Sony Ericson Smartphones erinnern. Inzwischen haben sich jedoch Googles Android (ca. 78% Marktanteil in Deutschland) und Apples iOS (22%) als Platzhirsche durchgesetzt – andere Betriebssysteme für mobile Endgeräte können heutzutage als Zielgruppe vernachlässigt werden.

Auch wenn sich die beiden Plattformen in den vergangenen Jahren mehr und mehr angeglichen haben, setzen beide Unternehmen weiterhin auf ihr eigenes Developer SDK (Software Development Kit) zur Entwicklung nativer Apps. Native Anwendungen sind direkt auf ein Endgerät installiert und bestmöglich auf das zu Grunde liegende Betriebssystem zugeschnitten. Moderne Android-Apps werden vorwiegend in Kotlin (ehemals Java) geschrieben, während das iOS SDK auf der Apple eigenen Sprache Swift (ehemals ObjectiveC) basiert. Eine native Android App kann nicht auf einem iOS Gerät ausgeführt werden und vice versa. Entsprechend ist die Entwicklung einer separaten Anwendung für die jeweilige Plattform notwendig. Abhilfe können Hybride-App-Entwicklung oder Web-App-Entwicklung schaffen.

Es gibt inzwischen ein riesengroßes Spektrum verschiedener App-Typen. Die nachfolgende Auflistung stellt diese dar und soll für etwas mehr Orientierung im Dschungel der App-Arten sorgen:

• Native App: Wie bereits erläutert, bezeichnet man Apps als nativ, wenn diese mit dem jeweils hauseigenen Android SDK (Koltin, Java) oder iOS SDK (Swift, ObjectiveC) für eine einzige Plattform entwickelt wurden. Sicherlich sind sie der meist-verbreitete App-Typ.
• Cross-Plattform-App: Als Cross-Plattform-Apps bezeichnet man mobile Anwendungen, welche einen Großteil der Code-Basis teilen und auf beiden mobilen und ggf. weiteren Plattformen (wie etwa in jedem Web-Browsers) nutzbar sind.
• (Progressive) Web-App (PWA): Sie können als mobil-optimierte Webseite betrachtet werden. Es ist keine Installation auf dem Gerät notwendig, dafür sind aber auch Hardwarefunktionalitäten, wie die Kamera oder GPS, nur sehr eingeschränkt nutzbar.
• Hybride App: Von einer hybriden App spricht man, wenn mit einem hybriden App-Entwicklungs-Framework – einer der bekanntesten Vertreter hier ist React Native – gearbeitet wird. Dabei wird dem App-Nutzer eine native App vorgegaukelt. Unter der Haube handelt es sich aber um eine Schnittstellenimplementierung, welche von dem zugrundeliegenden Betriebssystem abstrahiert und eine für Android und iOS einheitlich Basis bietet, auf welcher die eigentliche App erstellt wird. Die nativ-wirkenden UI-Elemente wie Buttons oder Eingabefelder werden dabei vom hybriden Framework in der Regel nachimplementiert. Innerhalb des hybriden Frameworks kann dann mit einer Programmiersprache (im Falle von React Native ist es JavaScript; bei Flutter die Sprache Dart) eine App für Android und iOS zugleich erstellt werden. Das vom Framework gewählt Abstraktionslevel beeinflusst letztendlich die Flexibilität des hybriden App-Entwicklers. Neben React Native gehören auch Flutter, Cordova, Xamarin und Ionic zu den hybriden App Frameworks.

Mit Kotlin Native stehen darüber hinaus auch noch weitere Hilfsmittel zur Verfügung, um Code zwischen unterschiedlichen Plattformen zu teilen: So können Teile der Business Logik einer App, bspw. komplexe Berechnungen oder die Kommunikation mit einem Server in Kotlin implementiert, eine für jede Plattform native Komponente (Bibliothek) generiert und dort genutzt werden. Unter anderem die UI Implementierung muss aber weiterhin nativ erfolgen.

In den vergangenen Jahren sind verschiedenste Unternehmen vermehrt auf den Zug der Cross-Plattform-App-Entwicklung aufgesprungen. Sie hatten zum Ziel – anstelle je eine separate Android und iOS App zu entwickeln – nur eine Codebasis pflegen zu müssen, schneller zur Marktreife zu gelangen, und letztendlich Kosten zu sparen. Doch selbst die Pioniere Facebook und AirBnB sind trotz signifikanter Investitionen in bspw. React Native nun wieder auf native App Entwicklung umgestiegen, da die Versprechen nicht gehalten werden konnten. Mehr Infos zu den genauen Gründen findest du hier.

Google hat mit Flutter im Dezember 2018 die erste Version eines neuen Cross-Plattform Toolkit veröffentlicht. Unsere ersten Eindrücke haben wir in folgendem Blog-Post zusammengetragen: Wie funktioniert Flutter und warum ist es wegweisend?

Seit jeher entwickeln wir verschiedene Prototypen und Produkte für Kunden mit Flutter. Flutter wird stets weiterentwickelt und verbessert. Ein großer Vorteil von Flutter ist die einfache Integration in eine bestehende Android/iOS App, so dass die Nutzung von Flutter experimentell für eine oder wenige neue Funktionen erprobt werden kann. Für eine prototypische Umsetzung zur Validierung einer neuen Geschäfts-/Produktidee eignet sich Flutter in vielen Fällen gut.

Ob wir dir darüber hinaus zum Einsatz von Flutter – oder einer alternativen Cross-Plattform-Technologie – raten, hängt stark von deinem konkreten Projekt, dessen Umfang und deiner Risikobereitschaft (Flutter steck schließlich noch in den Kinderschuhen) ab. Eine genaue Evaluation ist es aus unserer Sicht allemal wert. Indikatoren, die wiederum stark für eine native App-Entwicklung sprechen, sind etwa die Kommunikation mit externer Hardware via Bluetooth, WLAN oder ähnlichem, eine exzessive Integration und Anpassung der üblichen Kamera-Funktionalität oder eine umfängliche Offline-Fähigkeit der App.

Solltest du eine Enterprise App für das B2B-Umfeld konzipieren, empfehlen wir, genau zu evaluieren, ob sie tatsächlich Android und iOS – aufgrund der Präsenz beider Zielgruppen – unterstützen müssen oder ob sie sich ggf. sogar auf eine Plattform beschränken können. Die Anschaffungskosten weniger z.B Android-Geräte stehen in der Regel in keinem Verhältnis zu den Entwicklungskosten für eine weitere Plattform (iOS).

Egal ob du selbst eine App entwickelst oder eine App erstellen lässt, durchläuft diese unterschiedliche Phasen und Lebenszyklen – viele davon im Idealfall parallel und iterativ. Dabei ist für eine erfolgreiche Etablierung am Markt die reine Entwicklungsarbeit nicht genug.

Am Beginn steht die Definition der Zielgruppe und die Ausarbeitung eines Alleinstellungsmerkmals gegenüber den ggf. bereits existierenden Apps von Konkurrenten. Auf Basis dessen empfehlen wir, eine nutzerzentrierte Ausarbeitung des UX-Konzepts in Form von Wireframes, gefolgt von einer grafischen Ausarbeitung des UI-Designs. Dabei lassen sich bereits iterativ erste Annahmen validieren und entsprechendes Nutzerfeedback einarbeiten, bevor eine einzige Zeile Code erstellt wird.

Das App-Konzept inklusive Designs dient anschließend als Grundlage für die Technologie-auswahl zur App-Erstellung. Wie zuvor beschrieben gibt es die unterschiedlichsten Möglich-keiten, eine App Idee umzusetzen. In den häufigsten Fällen erfasst eine App eine Vielzahl an Daten, welche zentral in einem Backend-System abgelegt werden. Entsprechend gilt es, ein gewisses Sicherheitskonzept festzulegen und umzusetzen, um die Daten sicher zu speichern. Diese Informationen fließen dann in die entsprechende Systemarchitektur ein. Mit diesen Informationen kann dann schließlich die agile Entwicklungsarbeit aufgenommen werden.

An dieser Stelle verweisen wir für ausführlichere Informationen auf unsere beiden thematisch relevanten Blog-Artikel:

1. Insights into creating world-class Bluetooth connected mobile-Apps
2. Set up your Android project for success

Bei der Umsetzung und Entwicklung einer App inklusive Backend fallen einige sich wiederholende Aufgaben an, etwa das Deployment („Installation“) des Backends auf dem Server oder die Erstellung und Veröffentlichung der App-Artefakte in den App-Stores Google Play und iTunes. Diese und weitere Schritte können jedoch in einer so genannten Continuous Integration and Continuous Delivery Pipeline (CI/CD) automatisiert werden. Auch große Teile der – nachfolgend im Detail beschriebenen – Qualitätssicherung können in diese Automatisierung integriert werden, um stets höchste Produktqualität zu gewährleisten.

Sobald die erste Produktversion – ein so genanntes Minimum Viable Product (MVP) – steht, kann diese mit den ersten Alpha/Beta Testern evaluiert werden. Entsprechend kann die Veröffentlichung neuer App-Versionen sehr feingranular gesteuert werden.  Beispielsweise kann die neuste Version zunächst lediglich an Beta-Tester in Deutschland ausgespielt werden. Sollten die Ergebnisse zu vollster Zufriedenheit sein, kann die Zielgruppe stetig erhöht werden. Zudem besteht stets die Möglichkeit, für bestimmte Märkte – etwa die USA oder Asien – eine dedizierte App-Variante zu erstellen.

Zuletzt stellt sich noch die Frage, wie potenzielle Nutzer überhaupt auf Ihre App aufmerksam werden. Die Notwendigkeit von Marketing ist nicht zu unterschätzen, denn der App-Markt ist groß. Hier kann natürlich Werbung auf den einschlägigen Plattformen geschaltet werden. Ebenso ist entsprechende Pressearbeit und organische SEO-Optimierung zu empfehlen. Selbst ihr App-Eintrag in den App-Stores kann entsprechend optimiert werden. Wenn du deine Hausaufgaben entsprechend gemacht hast und die App Anklang bei der Zielgruppe findet und auch technisch hochwertig umgesetzt wird, kommst du ggf. in den Genuss, dass deine App in den Stores als „App der Woche“ oder ähnliches prominent platziert wird.

Elementarer Bestandteil unseres Entwicklungsprozesses sind die Qualitätssicherung und -kontrolle. Um manuellen Aufwand auf die wichtigen Aufgaben zu begrenzen und konstant höchste Qualität zu garantieren, sind diese im Rahmen einer so genannten Continuous Integration and Continuous Delivery (CI/CD) Pipeline von Beginn an implementiert: eine Abfolge an Maßnahmen und Analysen prüft ein jedes Projekt ab der ersten Zeile Code sowie jede weitere Änderung automatisiert. Änderungen werden isoliert entwickelt, analysiert und erst bei erfolgreicher Prüfung in das Projekt übernommen.

Konkret sieht diese Abfolge wie folgt aus:

1. Die Codebasis muss fehlerfrei kompilieren.
2. Statische Code-Analyse: Prüfung von Änderungen auf mögliche Fehlerquellen, einheitlichen Code-Stil und Best-Practices.
3. Automatisierte Unit- und UI-Tests: Müssen alle fehlerfrei sein mit einer Code-Abdeckung von 60-80 % (je nach Ihren Anforderungen pro Projekt; manche Teile des Codes können nicht automatisiert getestet werden)
4. Manuelle Überprüfung von Änderungen im Vier-Augen-Prinzip durch einen weiteren Entwickler – Änderungen werden mit eventuellen Kommentaren versehen, akzeptiert oder abgelehnt.
5. Automatisierte Bereitstellung der neuen App-Version für interne Nutzung.
6. Durchführung manueller Integrationstests anhand eines wachsenden Testscripts zur Überprüfung aller fachlichen Anforderungen.

Verschiedene Meilensteine haben unterschiedlich hohe Anforderungen. So kann sichergestellt werden, dass eine Beta-Version bereits alle manuellen Integrations-Tests erfüllt, während eine interne Version noch nicht den manuellen Test-Prozess durchlaufen muss, um bspw. effizient Experimente durchzuführen. Es wird jedoch keine öffentliche Version geben, die nicht auf Herz und Nieren geprüft und Belastungstests ausgesetzt wurde.

Sollte es trotz der genannten Maßnahmen doch einmal zu einem unerwarteten Problem kommen, ist jedes Projekt mit einem entsprechenden Monitoring und Reporting ausgestattet. So kann zügig auf auftretende Fehler reagiert und diese gelöst werden.