Automatisierte Generierung hybrider Apps für Mobile Devices

Inhaltsverzeichnis

1 Einleitung

2 Grundlagen des Mobile Computings
2.1 Mobile Devices
2.1.1 Smartphones
2.1.2 Tablets
2.2 Mobile Plattformen
2.2.1 iOS
2.2.2 Android
2.2.3 Weitere Plattformen
2.2.4 Plattformverbreitung
2.3 Apps für Mobile Devices
2.3.1 Native Apps
2.3.2 Web-Apps
2.3.3 Hybride Apps

3 Plattformübergreifende Entwicklung von hybriden Apps
3.1 Grundlegende Web-Technologien
3.1.1 HTML5, CSS3 und JavaScript
3.1.2 Responsive Web Design
3.1.3 Unterstützung von Displays mit hoher Pixeldichte
3.2 Frameworks
3.2.1 Web Application Frameworks
3.2.2 Wrapper Frameworks
3.2.3 Interpreter Frameworks
3.3 Automatisierung des Workflows
3.3.1 Zieldefinition
3.3.2 Erstellung von Templates
3.3.3 Etablierung eines Workflows im Content Management System
3.3.4 Automatisierte Zusammenstellung der Daten für die App
3.3.5 App Building
3.3.6 Publikation und Vermarktung
3.3.7 Aktualisierung der App-Inhalte
3.3.8 Chancen und Grenzen

4 Implementierung eines Prototyps
4.1 Zieldefinition
4.2 Auswahl der Technologien
4.3 Realisierungsphase
4.3.1 Templates für das Content Management System
4.3.2 Widget zur Nutzung von Features der Mobile Device APIs
4.3.3 Konsolidierungsschicht
4.3.4 Schnittstelle zwischen Content Management System und Konsolidierungsschicht
4.3.5 Crawler zur automatisierten Zusammenstellung der Daten
4.3.6 Schnittstelle zwischen Konsolidierungsschicht und Build Service
4.4 Testphase
4.5 Ergebnis
4.6 Lessons Learned

5 Schlussbetrachtung

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1: Produktübersicht als Use-Case-Diagramm

Abbildung 2: Strukturdiagramm zur Beschreibung des Build-Prozesses und der beteiligten Systeme

Abbildung 3: Anzeige der Daten einer App im GUI der Konsolidierungsschicht (Screenshot)

Abbildung 4: Klassendiagramm zu Model und Controller der App in der Konsolidierungsschicht

Abbildung 5: Anzeige der Daten einer App in JSON-Notation (Screenshot)

Abbildung 6: In Polopoly geöffnete Site mit den Inhalten der App (Screenshot)

Abbildung 7: Bearbeiten der Daten einer App in Polopoly (Screenshot)

Abbildung 8: Auslösen des Crawlens und Sendens an PhoneGap Build in Polopoly (Screenshot)

Abbildung 9: Bearbeiten von Icon, Splash Screen und config.xml in Polopoly (Screenshot)

Abbildung 10: Beispielhafter Weg des Crawlers durch eine Seitenstruktur

Abbildung 11: Darstellung der App in PhoneGap Build (Screenshot)

Abbildung 12: Darstellung der fertigen App auf einem Samsung Galaxy Nexus mit Android 4.2.1

Abbildung 13: Darstellung der fertigen App auf einem Apple iPad 2 mit iOS 6.0.1

Tabellenverzeichnis

Tabelle 1: Weltweite Marktanteile von Smartphone Betriebssystemen

Tabelle 2: Weltweite Marktanteile von Tablet Betriebssystemen

Tabelle 3: Beispiele für vom Crawler generierte absolute Pfade

Tabelle 4: Während der Testphase eingesetzte Mobile Devices

1 Einleitung

Tablets und erst recht Smartphones haben sich in den letzten Jahren zu unseren ständigen Begleitern entwickelt. Laut aktuellen Prognosen wird ihre Verbreitung in den kommenden Jahren noch weiter voranschreiten. Das Wachstum des Absatzes in diesen beiden Gerätegruppen wird deutlich höher liegen als bei klassischen Desktop Computern und Notebooks.^[1] Mit der steigenden Verbreitung von Mobile Devices wächst zugleich der Markt für mobile Apps. Diese über zentrale Stores verbreiteten Kleinanwendungen, die durch Apples iPhone populär wurden, bieten dementsprechend ein enormes Potential, das von der so genannten App-Economy erschlossen werden will.

Vor allem als Content-Plattform, zum Beispiel für Nachrichten oder Magazine, haben viele Anbieter diesen neuen Ausgabekanal für sich entdeckt. So kommt kaum noch ein Anbieter ohne eigene App aus. Doch bedeutet die Herstellung einer eigenen nativen App oft einen hohen Zeit- und Kostenaufwand. Selbst Apps mit simplen Inhalten müssen individuell für die einzelnen Plattformen entwickelt werden. Auch für die Pflege der Inhalte muss meist zusätzliche Infrastruktur geschaffen werden. Die Etablierung einer rein browserbasierten Web-App ist dabei, auf Grund der schlechteren Möglichkeiten zur Monetarisierung und fehlender Sichtbarkeit in den App Stores, meist keine Alternative. Hybrid-Apps bieten hier einen neuen, dritten Weg, der die Vorteile von nativen und Web-Apps verbinden kann.

Ziel der vorliegenden Arbeit ist, aufzuzeigen, wie plattformübergreifende Hybrid-Apps mit einem hohen Automatisierungsgrad aus einem bestehenden webbasierten CMS (Content Management System) heraus erstellt werden können. Hierzu wird zunächst ein Überblick über das aktuelle Umfeld für Mobile Computing gegeben. So werden die unterschiedlichen Typen von Mobile Devices ebenso wie die verschiedenen Plattformen beschrieben. Außerdem werden die Vor- und Nachteile nativer, Web- und hybrider Apps dargestellt. Darauf folgt eine Übersicht über die für die Entwicklung hybrider Apps verwendeten Technologien und Frameworks. In einem ausführlichen Konzept wird dargestellt, wie diese in einem automatisierten Workflow eingesetzt werden können, welche zusätzlichen Komponenten für die Anbindung eines CMS notwendig sind und welche Chancen und Risiken sich hieraus ergeben. Im Rahmen eines Software-Prototyps, der hier dokumentiert wird, soll die Machbarkeit des zuvor beschriebenen Konzepts unter Beweis gestellt werden. Die daraus gewonnenen Erkenntnisse führen zu einer zusammenfassenden Schlussbetrachtung.

2 Grundlagen des Mobile Computings

2.1 Mobile Devices

Eine einheitliche Definition für den Begriff der Mobile Devices existiert nicht. Die Abgrenzung zu anderen Geräteklassen erfolgt rein subjektiv. Üblicherweise werden unter dieser Bezeichnung jedoch kleine, leichte tragbare Computer mit eigener Stromversorgung zusammengefasst. Sie verfügen über Möglichkeiten der Konnektivität wie Telefonie, drahtlose Internetnutzung, Bluetooth und Near Field Communication. Zudem verfügen sie meist über einen Touchscreen und eine Kamera. Neben Smartphones und Tablets können somit grundsätzlich auch kleinere Notebooks, Feature Phones und eine Reihe spezialisierter Hardware zu diesem Bereich gezählt werden.

Im Rahmen dieser Arbeit soll ausschließlich auf die Gattung der Smartphones und Tablets eingegangen werden.

2.1.1 Smartphones

Seit der Einführung des iPhones im Jahr 2007 haben sich Smartphones als multimediale Gadgets etabliert, die neben einem Touchscreen weit mehr Funktionsumfang bieten als nur Telefonie und SMS und darüber hinaus softwareseitig nahezu beliebig erweitert werden können. Die verwendeten Betriebssysteme sind dabei deutlich komplexer als bei klassischen Mobiltelefonen. Laut einer von Google initiierten Studie verfügten im 1. Quartal 2012 bereits 29% der Bürger der Bundesrepublik Deutschland über ein Smartphone. Ein Jahr zuvor waren es lediglich 18%.^[2]

Der Formfaktor von Smartphones ist zumeist so ausgelegt, dass diese in der Hosentasche transportiert werden können. Damit gehören Smartphones zu den Devices mit dem höchsten Grad an Mobilität und können in sehr unterschiedlichen Kontexten eingesetzt werden. Sie werden sowohl zu Hause als auch unterwegs genutzt. Dabei liegt die vorrangige Motivation zur Nutzung im Bereich der Kommunikation.^[3]

2.1.2 Tablets

Im Vergleich zu Notebooks oder Netbooks sind Tablets meist leichter und verfügen über einen Touchscreen. Auch die Geräteklasse der Tablets erfuhr ihren Aufschwung durch ein Device von Apple. Das iPad gilt seither als Referenzprodukt. Vor der Vorstellung des iPads existierten zwar bereits verschiedene Tablet-Computer, deren Marktdurchdringung aber unbedeutend gering war. Der IT-Verband BITKOM sieht die Tablet Computer nun im „Dauerboom“. So stieg der Absatz von 2,1 Millionen im Jahr 2011 auf 3,2 Millionen in 2012, was einem Anstieg von 52% entspricht.^[4] Zudem ergab eine repräsentative Umfrage der BITKOM, dass bislang 13% der Bürger in Deutschland ein Tablet nutzen.^[5]

Tablets sind deutlich größer als Smartphones und bieten somit einen geringeren Grad an Mobilität. Sie werden überwiegend zu Hause genutzt. Die Motivation zur Nutzung liegt hier vor allem im Bereich der Unterhaltung.^[6]

2.2 Mobile Plattformen

In den vergangenen Jahren haben sich mehrere mobile Plattformen etabliert, die sowohl auf Smartphones als auch auf Tablets angewendet werden können. Sie zeichnen sich dadurch aus, dass sie nicht nur ein mobiles Betriebssystem, sondern ein vollständiges Ökosystem mit App-Stores, Content (beispielsweise Musik, Filme und Bücher), Cloud-Diensten und zum Teil auch mit passender Hardware bereitstellen.

Die mit Abstand größte Bedeutung haben hier iOS von Apple und Android, welches federführend von Google vorangebracht wird.

2.2.1 iOS

Apple führte mit dem ersten iPhone im Januar 2007^[7] auch sein neues Betriebssystem iOS vor, das zu diesem Zeitpunkt noch iPhone OS hieß. Es basiert auf Apples Desktop-Betriebssystem Mac OS und wird nur auf Hardware von Apple angeboten. Zusätzliche Software kann über den App Store bezogen werden. Über den Dienst iCloud lassen sich Daten über mehrere Devices hinweg synchronisieren.

Als einer der großen Vorteile der iOS-Plattform wurde immer der geringe Grad der Fragmentierung angeführt. Lediglich das iPhone, der iPod Touch und das iPad wurden mit diesem System ausgestattet. Dies hat sich inzwischen geändert. Seit dem iPhone 4 gibt es Retina Displays mit einer höheren Pixeldichte und das iPhone 5 weist nun sogar ein anderes Seitenverhältnis auf. Schließlich kam 2012 auch noch das iPad Mini hinzu. Für Entwickler bedeutet dies einen entsprechenden Mehraufwand.^[8]

2.2.2 Android

Die Android-Plattform ist seit 2007 das Hauptprodukt der Open Handset Alliance.^[9] Hierbei handelt es sich um ein Konsortium von Netzbetreibern, Geräte-, Halbleiter- und Softwareherstellern sowie Vermarktern. Treibende Kraft ist Google. Android wird als Open Source Projekt entwickelt und auf Devices unterschiedlicher Hersteller angeboten, die das System zum Teil mit einem eigenen GUI (Graphical User Interface) versehen. Über Googles Play Store, aber auch über mehrere Stores von Drittanbietern, kann zusätzliche Software bezogen werden. Außerdem besteht eine tiefe Integration mit weiteren Diensten von Google, beispielsweise der Google Suche, dem Social Network Google+ oder Gmail.

Ein erhebliches Problem von Android ist der hohe Grad der Fragmentierung. Im Vergleich zu iOS ist die Zahl der unterschiedlichen Formfaktoren deutlich höher. Zusätzlich läuft auch nur ein eher geringer Anteil der Devices auf der jeweils aktuellsten Betriebssystem-Version. So waren im Januar 2013 nur 10,2% der Devices mit der zu diesem Zeitpunkt aktuellsten Version „Jelly Bean“ (4.1 und 4.2) ausgestattet während 47,6% noch auf „Gingerbread“ (2.3.x) liefen.^[10] Somit profitieren nur wenige Anwender von den verhältnismäßig kurzen Innovationszyklen von Android.

2.2.3 Weitere Plattformen

In den vergangenen Jahren lief alles auf einen Zweikampf zwischen iOS und Android im Bereich der mobilen Plattformen hinaus. Dies schlägt sich auch in den Präferenzen der Entwickler von mobilen Apps nieder. Andere Plattformen werden auf Grund der geringen Verbreitung und damit verbundenen geringen Einnahmemöglichkeiten selten berücksichtigt.^[11] Dennoch existieren daneben noch weitere Systeme, welche eine Betrachtung wert sind.

Insbesondere im Businessbereich ist Blackberry trotz sinkender Marktanteile von Bedeutung.^[12] Nach wie vor werden Mitarbeiter von Unternehmen einheitlich mit diesen Geräten ausgestattet. Allerdings handelt es sich vor allem um Devices mit reiner Tastatursteuerung. Sowohl die mit einem Touchscreen versehenen Smartphones der Torch-Reihe als auch das Tablet Playbook konnten keine nennenswerten Marktanteile erzielen. Die völlig neu entwickelte und im Januar 2013 vorgestellte Plattform Blackberry 10 und neue Smartphones sollen helfen wieder an Bedeutung zu gewinnen.^[13] Auf älteren Geräten wird das neue Betriebssystem jedoch nicht lauffähig sein.^[14]

Mit Windows 8 und Windows Phone 8 versucht auch Microsoft, verloren gegangene Marktanteile im mobilen Bereich zurückzugewinnen. So erhielt das Desktop-Betriebssystem Windows in Version 8 eine für Touch-Displays optimierte Benutzeroberfläche und einen eigenen App-Store. Gleichzeitig kann auch klassische Windows-Software eingesetzt werden.^[15] Mit dem Surface-Tablet bietet Microsoft sogar eigene Hardware für diese neue Plattform an. Der Versuch, sowohl Tablets mit Touch- als auch PCs mit Maus- und Tastatursteuerung durch eine einzige Benutzeroberfläche zu steuern, ist in dieser Konsequenz neuartig. Dementsprechend zurückhaltend reagieren bislang die Entwickler von Apps.^[16]

Andere Plattformen können im Bereich der Smartphones und Tablets nur noch eine geringe oder sinkende Bedeutung aufweisen. Hierzu zählen Nokias Systeme Symbian und MeeGo oder auch Bada von Samsung. Gleichzeitig treten jedoch auch neue Plattformen an und wagen „[…] den Angriff auf das Duopol“^[17] von iOS und Android. Hier sind Tizen, Firefox OS sowie Ubuntu Mobile zu nennen. Deren Potential und somit deren Erfolgsaussichten sind derzeit jedoch noch nicht absehbar.

2.2.4 Plattformverbreitung

Da Studien über die Marktanteile der einzelnen Plattformen üblicherweise Smartphones und Tablets getrennt ausweisen, sollen diese auch an dieser Stelle einzeln betrachtet werden. Dies ist auch sinnvoll vor dem Hintergrund, dass die Verteilung der Anteile in den beiden Segmenten große Unterschiede aufweist. Die Zahlen beider nachfolgenden Tabellen wurden von IDC im Dezember 2012 veröffentlicht. Neben der für 2012 geschätzten Verteilung der weltweiten Marktanteile sind auch Prognosen für das Jahr 2016 berücksichtigt.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Weltweite Marktanteile von Tablet Betriebssystemen^[19]

Beim Vergleich zwischen 2012 und 2016 ist besonders hervorzuheben, dass von einer deutlich steigenden Bedeutung von Windows und Windows Phone ausgegangen wird. Neben den bereits jetzt dominierenden Systemen Android, iOS, Windows und bei den Smartphones auch Blackberry wird die Bedeutung anderer noch weiter abnehmen. Nach Einschätzung von IDC wird Android bei den Smartphones seine deutliche Marktführung ebenso behalten wie iOS bei den Tablets.

2.3 Apps für Mobile Devices

Der Begriff App ist eine Kurzform für Application und wurde zunächst von Apple für das iPhone im Zusammenhang mit Mobile Devices eingeführt. Die Bezeichnung „App“ ist zwar keineswegs auf mobile Anwendungen beschränkt, wird jedoch mittlerweile im allgemeinen Sprachgebrauch synonym hierfür verwendet.

Ursprünglich sollten über den Browser darstellbare Web-Apps als Standard auf dem iPhone verwendet werden. Da jedoch der Bedarf für erweiterte Funktionalität in den Programmen groß war, veröffentlichte Apple ein halbes Jahr nach der Vorstellung des iPhones ein SDK (Software Development Kit) zur Entwicklung nativer Applikationen.^[20]

Letztlich wurde das Konzept der in ein Ökosystem eingebetteten Apps ein entscheidender Faktor für den Erfolg des iPhones. Über einen zentralen Store können verschiedene Apps zu meist geringen Preisen oder auch kostenlos auf das Device geladen werden. Seit der Einführung des iPads werden Apps häufig auch für die Nutzung auf den unterschiedlichen Formfaktoren und Auflösungen angepasst. Zudem gilt das Prinzip, dass eine einmal erworbene App auf allen Geräten derselben Plattform mit demselben Benutzerkonto genutzt werden darf. Die Stores übernehmen dabei Speicherung und Installation der App sowie die Abbuchung. Hierfür wird jedoch auch ein Teil des Umsatzes von den Anbietern der Apps an den jeweiligen Store gezahlt.^[21] Neben den Apps werden auch Inhalte wie Musik, elektronische Bücher oder Filme angeboten.

Dieses Konzept ist auch auf den anderen gängigen Smartphone- und Tablet-Plattformen etabliert. Mit mehr als 50 Millionen täglichen App-Downloads ist Googles Play Store mittlerweile sogar erfolgreicher als der App Store von Apple mit über 33 Millionen Downloads.^[22]

Insbesondere auf der Android-Plattform existieren inzwischen sogar zahlreiche App-Stores von Drittanbietern. So konnte sich neben dem Play Store insbesondere der App-Shop von Amazon etablieren.^[23] Amazons Kindle Fire Tablets basieren zudem zwar auf Android, bringen jedoch ein völlig eigenes Ökosystem von Apps und Inhalten mit.

Es existieren verschiedene Möglichkeiten zur Monetarisierung von Apps. So kann die App im jeweiligen Store kostenpflichtig angeboten werden. Die Preise werden hier von den Anbietern der Stores gestaffelt. Diese Staffelung kann auch durchaus ohne Vorankündigung verändert werden, wie zuletzt im Oktober 2012 bei Apple geschehen.^[24] Zudem ist immer ein gewisser Anteil der Einnahmen des App-Anbieters als Provision an den Store zu entrichten. Das Preisniveau differiert zwischen den unterschiedlichen Plattformen. Ebenso sind regionale Unterschiede festzustellen. Auch beim so genannten In-App-Purchasement sind die Preise nicht frei wählbar und ein Teil der Einnahmen muss abgegeben werden. Hierbei werden innerhalb der App Erweiterungen oder Inhalte verkauft. So können beispielsweise bei Spielen zusätzliche Level oder Fähigkeiten kostenpflichtig freigeschaltet werden. Auch journalistische Angebote nutzen diese Technologie, um Inhalte einzeln oder im Abonnement zu verkaufen. Zudem lassen sich Einnahmen durch das Anzeigen von Werbung innerhalb der App erzielen. Hier gibt es auf den mobilen Plattformen unterschiedliche Werbenetzwerke. Kostenlose aber durch Werbung oder In-App-Purchasement finanzierte Apps sind insbesondere vor dem Hintergrund besonders zu beachten, dass laut Gartner bereits 89% der 2012 weltweit heruntergeladenen Apps kostenlos waren.^[25] Dieser Anteil soll zukünftig sogar noch weiter steigen.

Ein nicht zu unterschätzendes Risiko für den App-Anbieter bei der Publikation seiner Apps in den jeweiligen Stores ist der so genannte Review-Prozess. Hierbei prüfen die Store-Anbieter neu eingereichte oder aktualisierte Apps bevor sie diese in den Stores freigeben. Dieser Prozess kann durchaus mehrere Tage dauern. Zudem sind eine Ablehnung der App sowie das spätere Löschen von Installationen durch den Store-Anbieter aus der Ferne möglich.^[26] Insbesondere Apple ist hier besonders restriktiv. So werden neben Apps mit technischen Fehlern oder Hinweisen auf konkurrierende Plattformen auch solche abgelehnt, die nicht gewissen Moralvorstellungen entsprechen oder eine Funktion anbieten, die bereits im Betriebssystem vorhanden ist. Letzteres kann auch im Nachhinein geschehen.^[27]

2.3.1 Native Apps

Native Apps sind auf die jeweilige Zielplattform angepasste Programme. Sie werden für jede Plattform mit Hilfe der jeweiligen SDKs erstellt und können in App Stores veröffentlicht werden.

Größter Vorteil nativer Apps ist ihre nahtlose Integration in die Plattform. So lassen sich beispielsweise Push-Nachrichten auf das Device senden. Außerdem kann auf Hardware-Funktionen wie Kamera, GPS (Global Positioning System) oder Neigungssensoren zugegriffen werden. Auch ein Zugriff auf das Dateisystem ist möglich, um beispielsweise zuvor heruntergeladene Daten auch offline vorhalten zu können. Über entsprechende Schnittstellen können verschiedene Apps auch untereinander kommunizieren. Durch die plattformnahe Programmierung lässt sich eine optimale Performance erzielen.^[28]

Hieraus ergibt sich jedoch zugleich der größte Nachteil nativer Apps. Sie müssen für jede Plattform neu programmiert und optisch angepasst werden. Dabei sind nicht nur die unterschiedlichen Eigenschaften der Hardware zu berücksichtigen, sondern auch der Einsatz verschiedener Programmiersprachen.^[29] So findet bei iOS Objective C Anwendung, während bei Android und Blackberry unterschiedliche Implementierungen von Java eingesetzt werden und Microsoft bei Windows Phone und Windows 8 vor allem auf die .NET-Technologien mit C#, C++ und VB.NET setzt.^[30] Die Wiederverwendbarkeit von Quellcode über mehrere Plattformen ist somit nahezu unmöglich.

Problematisch ist zudem, dass jede Plattform ihr eigenes SDK und oftmals auch eine eigene Entwicklungsumgebung mitbringt. Jedoch sind nicht alle SDKs auf allen Desktop-Betriebssystemen erhältlich. So kann für iOS nur auf einem System mit Mac OS entwickelt werden, während Windows Phone ein Windows-System voraussetzt. Die Entwicklung für Windows Phone 8 erfordert gar Windows 8 als Entwicklerbetriebssystem.

Die Fragmentierung von Hardware und Software hat somit einen erheblichen Einfluss auf die Wirtschaftlichkeit von Apps, die auf möglichst vielen Plattformen und Gerätetypen lauffähig sein sollen.

2.3.2 Web-Apps

Eine völlig andere Herangehensweise bildet die Erstellung von Web-Apps. Dies sind Webseiten, die für die Bildschirmauflösung der jeweiligen Devices optimiert sind und im Browser aufgerufen werden. Technologisch basieren diese Apps auf den Standards HTML (Hypertext Markup Language), CSS (Cascading Stylesheets) und JavaScript. So ist der plattformübergreifende Einsatz von Web-Apps möglich. Sie müssen somit nur ein einziges Mal entwickelt werden.^[31] Da die populärsten Plattformen moderne Browser, meist auf Basis der Webkit-Engine, verwenden, ist der Einsatz der zukünftigen Standards HTML5 und CSS3 möglich. Prinzipiell sind diese Apps auch auf klassischen Desktop-Computern verwendbar.

Da sowohl HTML5 als auch CSS3 noch keine offiziellen Standards sind, sind Änderungen an der Implementierung und Abweichungen zwischen den Interpretationen in den verschiedenen Browsern nach wie vor zu berücksichtigen.^[32]

Anders als bei nativen Apps besteht für die Veröffentlichung von Web-Apps keine Abhängigkeit vom Anbieter eines App-Stores.^[33] Es ergeben sich auch nicht die üblichen Verzögerungen durch den Review-Prozess des Stores beim Veröffentlichen eines Updates. Zudem müssen keine etwaigen Provisionen an den Anbieter des Stores entrichtet werden. Dafür ist die Sichtbarkeit einer Web-App durch ihre Abwesenheit in den Stores ungleich niedriger. Sie wird zwar durch die üblichen Suchmaschinen gefunden und kann durch eine Verknüpfung auf dem Smartphone oder Tablet wie eine native App gestartet werden, doch die Wahrnehmung entspricht trotzdem eher der einer Webseite als der einer App. Jedoch existieren mit Verzeichnissen wie OpenAppMkt^[34] Möglichkeiten, Web-Apps über ähnlich den nativen App-Stores aufgebaute Plattformen bekannt zu machen.

Die Einbindung von Gerätefunktionen ist in Web-Apps im Vergleich zu den nativen Apps deutlich eingeschränkt. So erlaubt beispielsweise das iPad keinen Zugriff aus dem Browser heraus auf das Dateisystem. Auch ein Zugriff auf die integrierte Kamera besteht bislang nicht. Zumindest ist jedoch das Arbeiten ohne Internetverbindung grundsätzlich möglich. Über die in HTML5 vorgesehenen Local Storages können Daten auf dem Device gespeichert werden.^[35] Auch auf GPS-Daten kann aus dem Browser heraus zugegriffen werden.^[36] Das Anbieten von In-App-Purchasement über die jeweils genutzte Plattform ist ebenfalls nicht möglich. So muss für das Payment jeweils auf Drittanbieter wie PayPal zurückgegriffen werden. Unter Umständen muss der User hierfür eine zusätzliche Registrierung vornehmen, was eine weitere Hemmschwelle vor dem Kauf darstellt. Populäres Beispiel für eine mobile Web-App mit eigenem Payment ist die der Financial Times.^[37]

2.3.3 Hybride Apps

Eine Möglichkeit, die Vorteile von nativen und Web-Apps zu verbinden, bieten hybride Apps. Sie stellen eine Mischform dieser beiden Ansätze dar. Hierbei werden die eigentlichen Inhalte mit Web-Technologien wie HTML, CSS und JavaScript erstellt und mit Hilfe eines Wrappers anschließend mit einem nativen Rahmen für die jeweilige Zielplattform versehen. Dieser Rahmen enthält einen integrierten Browser in Form einer Webview, die die Inhalte darstellt. Gleichzeitig bieten diese Wrapper Schnittstellen zu Funktionen des Mobile Devices, die über JavaScript angesprochen werden können. Zusätzliche Funktionen können oft über Plugins nachgerüstet werden.

Statt eines Wrappers können auch Interpreter zum Einsatz kommen, die JavaScript-Code zur Laufzeit als nativen Code der jeweiligen Plattform interpretieren.

Der große Vorteil hybrider Apps liegt darin, dass die Entwicklung und auch die Pflege und Weiterentwicklung des Inhaltsteils nur ein einziges Mal stattfinden müssen. Gleichzeitig ist trotzdem eine Präsenz in den nativen App-Stores möglich. Entwickler, die bislang Webseiten erstellt haben, können dank des hybriden Ansatzes relativ schnell auch Apps entwickeln ohne gleich mehrere neue Programmiersprachen erlernen zu müssen.^[38]

Einige Nachteile der nativen wie auch der Web-Apps bleiben jedoch beim hybriden Ansatz bestehen. So werden für die Generierung des nativen Teils nach wie vor die SDKs der jeweiligen Zielplattformen benötigt. Hier existieren allerdings bereits Lösungen, bei denen diese Generierung durch einen Cloud-Dienst bewerkstelligt wird. Weiterhin bleibt jedoch die Abhängigkeit von den Anbietern der App-Stores bestehen. Hybride Apps, deren Anmutung zu sehr der einer Webseite gleicht, sind hierbei besonders gefährdet, keine Freigabe zu erhalten.^[39] Gleichzeitig müssen UI (User Interface) und UX (User Experience) auf allen Zielplattformen funktionieren, was schwierig zu erreichen ist.^[40] Es kann hierbei nur eingeschränkt auf native GUI-Komponenten zurückgegriffen werden. Diese müssen somit mit Web-Technologien nachgebaut werden. Auch greift der Geschwindigkeitsvorteil nativer Apps nicht. Da die eigentlichen Inhalte in einem integrierten Browser dargestellt werden, ist die Performance eher mit der einer Web-App vergleichbar.^[41] Hierdurch ist ein hybrider Ansatz nicht für jede Art von App sinnvoll. Auch können unter Umständen nicht alle Funktionen aller Plattformen genutzt werden. Neue Funktionen müssen immer zunächst in den Wrapper und Interpreter Frameworks implementiert werden.^[42]

[...]

---

^[1] Der Absatz von Smartphones soll laut einer Prognose von IDC bis 2016 um 96% steigen, der von Tablets um 131%. Vgl. Brandt (2013)

^[2] Vgl. Google (2012a), S. 6

^[3] Vgl. Google (2012b), S. 13

^[4] Vgl. BITKOM (2012a)

^[5] Vgl. BITKOM (2012b)

^[6] Vgl. Google (2012b), S. 14

^[7] Vgl. Apple (2007)

^[8] Vgl. Appcelerator (2012), S. 5

^[9] Vgl. Open Handset Alliance (2007)

^[10] Vgl. Android Developers (2013)

^[11] Vgl. Appcelerator (2012), S. 3

^[12] Enough (2012), S. 24

^[13] Vgl. Halliwell (2013)

^[14] Vgl. Enough (2012), S. 32

^[15] Vgl. Enough (2012), S. 84

^[16] Vgl. Appcelerator (2012), S. 6 f.

^[17] Metz (2013)

^[18] Daten von IDC (2012a)

^[19] Daten von IDC (2012b)

^[20] Vgl. Franke, Ippen (2012), S. 23

^[21] Vgl. Franke, Ippen (2012), S. 25 ff.

^[22] Vgl. Enough (2012), S. 196

^[23] Vgl. Gartner (2012)

^[24] Vgl. Schwan (2012)

^[25] Vgl. Gartner (2012)

^[26] Vgl. Franke, Ippen (2012), S. 26 f.

^[27] Vgl. Apple (2013)

^[28] Vgl. Franke, Ippen (2012), S. 382

^[29] Vgl. Franke, Ippen (2012), S. 382 f.

^[30] Vgl. Enough (2012), S. 3

^[31] Vgl. Franke, Ippen (2012), S. 22

^[32] Seit Dezember 2012 existiert eine als Candidate Recommendation bezeichnete Spezifikation von HTML 5.0. Nach aktuellen Plänen der HTML Working Group des W3C soll sie bis Ende 2014 in genau dieser Fassung verabschiedet werden. Einige ursprünglich eingeplante Features werden jedoch in das erst 2016 erwartete HTML 5.1 verschoben werden. Vgl. W3C (2012a) sowie W3C (2012b)

^[33] Vgl. Franke, Ippen (2012), S. 27

^[34] http://openappmkt.com

^[35] Vgl. Kröner (2010), S. 151 ff.

^[36] Vgl. Kröner (2010), S. 145 ff.

^[37] http://app.ft.com

^[38] Vgl. Warren (2012)

^[39] Vgl. Apple (2013)

^[40] Vgl. Enough (2012), S. 96 f.

^[41] Vgl. Wyllie (2012), S. 150 sowie Warren (2012)

^[42] Vgl. Warren (2012)