© Maria Rudi/S&S Media
Wege zur mobilen App - Teil 1

Moderne Ansätze - eine Review


iOS und Android sind die beiden maßgeblichen Betriebssysteme auf dem Smartphone. Die Optionen, eine App für beide Systeme zu erstellen, sind dennoch sehr vielfältig. Ab und an ist es an der Zeit, die Möglichkeiten zu sortieren und für Orientierung zu sorgen.

Smartphones werden nun seit vielen Jahren in allen Lebensbereichen eingesetzt. Zunehmend werden Apps für die mobilen Systeme auch in Unternehmen verwendet (Mobile Enterprise Computing). Sie sind ein entscheidender Treiber der digitalen Transformation. Es folgt ein ungebrochener Bedarf an spezifischen Apps für die unterschiedlichsten Anforderungen. Der Prozess der App-Entwicklung unterscheidet sich nicht von der Herstellung von Software für andere Systeme. Weder hinsichtlich des Funktionsumfangs noch in Bezug auf die Komplexität stehen Apps anderer Software nach. Der Entwicklungszyklus in Meilensteinen, von der Idee (Auftrag, Konzept) bis hin zum erfolgreichen App-Store-Launch, sehen Sie in Abbildung 1.

bochkor_appentwicklung_teil_1_1.tif_fmt1.jpgAbb. 1: Der App-Entwicklungszyklus in Meilensteinen

Der gestiegene Bedarf an Apps für die mobilen Systeme führt auch dazu, dass die dafür verfügbare Zeit zur Entwicklung sehr oft knapp bemessen ist. In einigen Fällen ist es sogar so, dass wir eine App für einen bestimmten und sehr begrenzten Zeitraum benötigen und danach kein Bedarf mehr an der App besteht („Wegwerf-App“). Beispiele sind die App für eine (einmalige) Veranstaltung oder eine bestimmte Marketingaktion. Welche Beweggründe auch immer bestehen, eine App zu erstellen, es stellt sich dabei immer die Frage nach der passenden Vorgehensweise.

Obwohl wir es lediglich mit zwei aktiven Systemen, Android und iOS, zu tun haben, gibt es in der Zwischenzeit eine Reihe von sehr unterschiedlichen Vorgehensweisen, um das Ziel, eine auf dem Smartphone lauffähigen App zu erstellen, zu erreichen. Diese Tatsache muss etwas näher betrachtet werden. Die Hersteller der Betriebssysteme Android und iOS haben selbstverständlich einen eigenen Weg vorgesehen, der zu einer App für ihr jeweiliges System führt. Das Ergebnis ist eine sogenannte native App und ermöglicht, alle Optionen der jeweiligen Plattform zu nutzen. Die Gründe, nach alternativen Vorgehensweisen zu suchen, bzw. warum sehr viele unterschiedliche Ansätze angeboten werden, sind nach meiner Einschätzung die folgenden:

  • Apps für beide Systeme aus einer Quellcodebasis: Beide Systeme unterscheiden sich technisch erheblich. Soll eine App für beide Systeme angeboten werden, wie es in der Regel die übliche Anforderung ist, muss man nahezu den kompletten Entwicklungszyklus doppelt durchlaufen. Ggf. können die Phasen Konzeption und Prototyping verkürzt ausfallen, da man von wechselseitigen Synergien profitieren kann. Neben dem nahezu doppelten Aufwand braucht man auch zwei Teams. Die notwendigen Fähigkeiten sind ebenfalls sehr unterschiedlich.

  • Zeitfaktor (Time to Market): Die plattformspezifischen Ansätze sind nicht dafür bekannt, dass sie einen schnellen Entwicklungszyklus unterstützen. Der Vorteil, alle Möglichkeiten eines Systems auszuschöpfen, führt teilweise auch dazu, dass umfangreicher Quellcode zu schreiben ist. Ein typisches Beispiel ist die Prüfung von Berechtigungen auf der Android-Plattform. Aus oben genannten Gründen kann es erforderlich sein, sehr schnell zu ersten Ergebnissen mit einer lauffähigen App zu kommen. Gefragt sind daher insbesondere Ansätze, die den Aufwand reduzieren. Im Mittelpunkt steht dabei die Gestaltung der Benutzeroberfläche und die Umsetzung von Standardanforderungen wie der Prüfung von Berechtigungen.

  • Kenntnisse in den Programmiersprachen: Für die native Entwicklung muss man die Programmiersprachen anwenden, die die Hersteller der Systeme dafür vorschlagen. Programmiert man nur gelegentlich eine App bzw. ist man in einem grundsätzlich anderen Technologiestack zu Hause, kann das eine große Hürde darstellen.

  • Vorhandener Quellcode: Ist bereits Quellcode aus anderen Projekten – zum Beispiel zur Businesslogik oder zur Anbindung eines Backends – vorhanden, kann es ggf. gelingen, bestimmte Bestandteile dieses Codes wiederzuverwenden und auf diese Weise wertvolle Ressourcen zu sparen.

Sie sehen, es gibt unterschiedliche Gründe, nach alternativen Vorgehensweisen zur App-Entwicklung gegenüber den von Apple und Google angebotenen systemeigenen Entwicklungswerkzeugen, Sprachen und Frameworks Ausschau zu halten. Je nach angewendeter Technologie kommen wir dabei zu unterschiedlichen Ergebnissen. Diese sind Gegenstand des kommenden Abschnitts.

Nativ, Web, Hybrid, Cross-Plattform

Aus enger technischer Perspektive kann man bekanntermaßen folgende Arten von Apps unterscheiden:

  • native Apps

  • Web-Apps

  • hybride Apps

Native Apps werden exklusiv für das Zielsystem, d. h. Android oder iOS, erstellt. Man nutzt direkt das API der Systeme. Die Benutzeroberfläche fügt sich exakt in die Vorgaben der Plattform ein und auch die Benutzerführung ist mit der Systemumgebung kompatibel. Nutzer müssen sich also nicht erst länger orientieren, d. h. sie sind mit den üblichen Vorgängen, wie der Auswahl bzw. dem Löschen von Elementen oder dem Wechseln zwischen den Screens einer Anwendung, sofort vertraut. Ein weiterer wichtiger Vorteil besteht darin, dass native Apps keine Einschränkungen beim Zugriff auf mögliche spezifische Gerätehardware des Smartphones oder Tablets aufweisen. Alle Sensoren dieser Geräte können direkt angesprochen werden. Auch werden die Funktionen von neuen Geräten vollständig unterstützt und können damit in der eigenen App verwendet werden. Das Deployment erfolgt über die App-Stores. Ist eine native App installiert, kann diese – sofern sinnvoll – auch ohne Internetzugriff ausgeführt werden, d. h., dass ein Offlinebetrieb möglich ist. Eine notwendige Datensynchronisation kann beim Herstellen der nächsten Onlineverbindung des mobilen Gerätes automatisch stattfinden. Web-Apps sind dagegen auf die mobilen Devices ausgerichtete Webapplikationen (Mobile First). Das betrifft primär die Gestaltung des User Interface. Der Zugriff auf die Systemhardware ist eingeschränkt. Einige Basisfunktionen, wie zum Beispiel die Ortung via GPS, sind jedoch möglich. Eine Bereitstellung über die Stores ist nicht möglich. Die Apps laufen auf dem Server und benötigen daher eine stetige Internetverbindung. Jedoch kann man ein Icon auf dem Home Screen einrichten, so dass die Nutzer keine Hürden beim Start der App haben. Web-Apps können aus Kundensicht immer dann eine Alternative sein, wenn man dem Nutzer eine Installation nicht zumuten möchte (zusätzlicher Aufwand) bzw. eine Version der Applikation für größere Devices (Desktop) besteht und diese an die mobilen Geräte angepasst werden soll. Ein Beispiel ist der Einsatz einer App für Zwecke des Marketings am Point of Sale. Ein QR-Code für den korrekten Link zur Internetadre...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang