Entwicklungsansätze für mobile Geräte
Wege nach Rom
App ist nicht gleich App. Manche passen sich hundertprozentig in die Betriebssystemumgebung ein, andere sind plattformübergreifend und weniger tief ins Zielsystem integriert. Wieder andere benötigen einen Webbrowser zur Ausführung. Für alle gibt es passende Werkzeuge, die die Entwicklung erleichtern.
Zwar führen viele Wege nach Rom, auf die App-Entwicklung übertragen können sie aber ziemlich steinig sein. Das Angebot an Werkzeugen ist groß und nicht jedes Tool eignet sich gleichermaßen für jede App. Bevor er sich auf den Weg macht, muss der Entwickler zunächst entscheiden, welche Art App er für welche Plattform programmieren will. Man unterscheidet native und webbasierte Apps. Irgendwo in der Mitte stehen hybride Apps. Möchte man mehrere Plattformen gleichzeitig bedienen, muss man sich mit plattformübergreifenden Programmiermodellen auseinandersetzen.
Dieser Artikel gibt einen Überblick über die zahlreichen technischen Ansätze, eine App für ein Smartphone oder Tablet zu programmieren. Eine Systematisierung kann dabei helfen, für ein neues Projekt den richtigen Entwicklungsansatz schneller zu finden.
Die beiden Hauptplattformen sind Android (Google) und iOS (Apple). Sie dominieren weltweit den Markt der Consumer-Geräte. Für Tablets kommt noch Windows 10 hinzu (siehe „Apps für die UWP“). Mit der Aussage von Microsoft, dass man Windows 10 Mobile nicht mehr aktiv weiterentwickelt, wird dieses Betriebssystem wohl endgültig aus dem Smartphone-Markt verschwinden.
Man unterscheidet zwischen den drei genannten Varianten native Apps, Web-Apps und hybride Apps. Für jedes System existiert eine vom Hersteller vorgesehene Variante, eine native App zu entwickeln. Der Vorteil einer solchen Applikation liegt darin, dass sie für das jeweilige Betriebssystem optimiert sind. Das User Interface fügt sich zu hundert Prozent in die Vorgaben der Plattform ein, sodass die Benutzerführung mit der Systemumgebung kompatibel ist. Anwender müssen sich also nicht erst orientieren, sondern sind mit den üblichen Vorgängen wie der Auswahl, dem Löschen von Elementen oder dem Wechseln zwischen den Screens einer Anwendung sofort vertraut.
Zudem unterliegen native Apps keinen Einschränkungen beim Zugriff auf spezifische Gerätehardware des Smartphones oder Tablets. Alle Sensoren dieser Geräte lassen sich über die APIs des Systems direkt ansprechen. Die Funktionen neuer Geräte werden vollständig unterstützt und Entwickler können sie in ihrer eigenen App verwenden.
Das Deployment nativer Apps erfolgt – mit Ausnahmen für die Entwicklung oder für Unternehmens-Apps – ausschließlich über die öffentlichen App-Stores. Der Offlinebetrieb dieser Apps ist bei Bedarf grundsätzlich möglich, die notwendige Datensynchronisation kann beim Herstellen der nächsten Onlineverbindung automatisch stattfinden.
Dem gegenüber stehen Web-Apps, die für die Nutzung auf den mobilen Geräten besonders angepasst werden müssen, unter anderem in Hinsicht auf die Nutzerführung und die Gestaltung des UI. Ihr Zugriff auf die Systemhardware ist weitgehend beschränkt, einige Funktionen, etwa den Ortungsdienst, können sie jedoch nutzen. Die Darstellung erfolgt im Browser des Systems und kann die Besonderheiten der einzelnen Plattform nur bedingt berücksichtigen.
Klassische Web-Apps kann man nicht über den App-Store bereitstellen. Sie laufen auf dem Server und benötigen daher eine permanente Internetverbindung. Damit ist eine Web-App die funktionelle Erweiterung einer mobilen Webseite, das heißt, sie kommt immer dann zum Einsatz, wenn man mehr Funktionen auf Ebene des Business-Layers realisieren muss. Die Übergänge zur klassischen Webseite sind jedoch fließend.
On- und offline unterscheiden
Die genannten können neuere technische Ansätze teilweise aufheben. Ein solcher Ansatz wird derzeit unter dem Stichwort Progressive Web App (PWA) diskutiert. Eine PWA ist gewissermaßen eine Symbiose aus einer Webseite und einer App. PWAs werden mit HTML5, CSS3 für die Gestaltung der Oberfläche und JavaScript für die Umsetzung der Geschäftslogik realisiert. Zusätzlich dienen Service Worker dazu, durch ein Caching eine Offlinefunktion zu bieten. Dieser Service Worker ist zwischen dem Webserver und der App auf dem mobilen Gerät geschaltet.