Wieder so ein Thema, bei dem sich die Gemüter erhitzen: HTML5 wird von vielen als “die” Entwicklungsplattform der Zukunft gesehen, wenn es um mobile Applikationen geht. Andere wiederum sind der Meinung, dass wirklich ernsthafte Anwendungen nativ entwickelt werden müssen. Und wieder bin ich der Meinung: So pauschal lässt sich das nicht sagen – auch wenn die Entscheidungsfindung hier leichter fällt, als z. B. bei der Diskussion um das passende Betriebssystem.
Auf den ersten Blick liegen die schwerwiegenden Vor- und Nachteile sehr schnell auf der Hand: Native Anwendungen laufen nur auf der jeweiligen Zielplattform, HTML5 auf allen. Die Schlussfolgerung: Wenn ich also meine App als HTML5-App entwickle, dann läuft sie direkt auf allen Geräten. So einfach ist das. Oder nicht?
Über was reden wir?
Fassen wir zunächst einmal kurz die Faktenlage zusammen:
- Native Anwendungen werden in der Sprache des jeweiligen Betriebsystems entwickelt, also Objective-C bei iOS, Java bei Android, .net bei Windows Mobile und Windows Phone. Native Anwendungen können das volle funktionale Potenzial des Gerätes ausschöpfen, sind – sofern sauber entwickelt – recht performant und nutzen meist das native User Interface des jeweiligen Betriebssystems. Tolle Sache. Sie funktionieren auch ohne aktive Datenverbindung und können z. B. dank Sandboxing höchste Sicherheitsstandards erfüllen, wenn man weiß wie’s geht.
- Die sogenannten HTML5-Apps bedienen sich zum Großteil an JavaScript – und eben HTML5. Es gibt sie als reine Online-WebApps, sie können aber dank der neuen Möglichkeiten von HTML5 durchaus teilweise auch lokal im Browser genutzt werden, wenn keine Datenverbindung vorhanden ist. Mit dem Zugriff auf Gerätefunktionen ist es so eine Sache, denn schließlich sind die Schnittstellen zu Bluetooth, Bewegungssensor oder z. B. Sprachassistenten auf den verschiedenen Plattformen proprietär. Außerdem stößt man in Sachen Sicherheit rasch an Grenzen. Ein Web-Entwickler ist aber vielleicht auch schneller gefunden als jemand, der bereits umfassende Erfahrungen mit Objektive-C und Cocoa Touch vorweisen kann.
- Eine Kombination aus beidem ist sicherlich ein vielversprechender Ansatz: Ein sogenannter Hybrid Web Container (es gibt vermutlich viele hundert verschiedene Begriffe für so etwas) bietet eine Art virtuelle Laufzeitumgebung (der Container) und damit eine einheitliche Schnittstelle zu den proprietären Funktionen des Gerätes, die dann im Rahmen einer Scriptsprache für eine plattformübergreifende Anwendung genutzt werden können. Dies ist in etwa vergleichbar mit dem Ansatz von Adobe Flash: Ein Player – verfügbar für verschiedenste Betriebssysteme und Browser – bietet einen einheitlichen Rahmen zur Entwicklung von Anwendungen. Das nennt man dann Cross-Platform-Development.
Spätestens hier will ich nicht weiter auf die technischen Details eingehen, denn die sind reichlich komplex und vielseitig. Außerdem ist das Thema Cross-Platform-Development äußert facettenreich, denn es geht nicht immer nur um einen Container oder Player, sondern eigentlich auch um Frameworks, APIs und viele andere Feinheiten. Experten werden mich für diese Oberflächlichkeit verurteilen, denn sie wird der Vielfalt an Lösungsansätzen wirklich nicht gerecht. Aktuelle Studien zählen an die 100 verschiedene Lösungen für Cross-Platform-Development auf dem Markt. Ein Deep-Dive würde hier aber zu weit führen.
Es kommt auf den Anwendungsfall an
Einen einfachen Geschäftsprozess wie z. B. die Genehmigung eines Reiseantrages kann man wunderbar Cross-Platform entwickeln. Er hat vielleicht nur 2 Buttons: Approve und Decline. Außerdem noch etwas Text zur Begründung und den Namen des Antragstellers. Der Anwendungsfall bietet in der Regel nur dann einen Mehrwert, wenn die Daten in Echtzeit verarbeitet werden. Das wäre also ein einfaches, reines Onlineszenario, das ich mit einer Cross-Platform-App schnell und effizient auf verschiedene mobile Betriebssysteme ausrollen kann.
Eine vollumfängliche Service-Management-Applikation für Feldtechniker sollte allerdings auch in einem Fahrstuhlschacht ohne UMTS-Verbindung funktionieren. Außerdem sollen ggf. technische Dokumente offline verfügbar sein und sich bei nächster Gelegenheit automatisch auf den neuesten Stand bringen. Bestimmt gibt es hier noch weitere Anforderungen, die eher für eine native Entwicklung sprechen, wie etwa die Nutzung des Bewegungssensors zur Umsetzung von Augmented Reality Features.
Derzeit sagen wir unseren Kunden ganz klar, dass der richtige Weg vom jeweiligen Geschäftsfall und dessen Anforderungen abhängt. Die Entscheidungsfindung kann man mit entsprechenden Entscheidungsbäumen sehr gut unterstützen. Solche Entscheidungsbäume sollten Teil einer mobilen Strategie sein.
Ist es die Zukunft?
Für viele geht es eher langfristig um die Frage: “Ist HTML5 die Zukunft”? Ich glaube ja – es wird zumindest Teil unserer Zukunft sein. Für einige unserer Kunden ist eine dahingehende Ausrichtung bereits heute der ideale Weg. Hierzu zählen z. B. Versicherungen, die sich aufgrund der äußerst heterogenen Gerätelandschaft ihrer Nutzer kaum auf spezifische Betriebssysteme festlegen können. Die Rahmenbedingungen geben hier die Richtung vor.
Ich kann mir allerdings nicht vorstellen, dass sich die zahlreichen Hersteller von Smartphones und Tablet-PCs in absehbarer Zeit auf einen homogenen Entwicklungsstandard einigen, der es erlaubt, mit einer übergreifenden Programmiersprache wirklich alle bereits existierenden und noch kommenden Innovationen in Mobile Devices einheitlich zu nutzen. Immer dann, wenn verschiedene Parteien unterschiedliche Ideen und Konzepte verfolgen, immer dann muss ein Kompromiss her. Ich glaube, HTML5 (stellvertretend für den eigentlichen Gedanken einer plattformunabhängigen Entwicklungsbasis) kann ein solcher Kompromiss sein. Nun muss man allerdings von Fall zu Fall selbst entscheiden, ob man einen solchen Kompromiss eingehen will und kann. Er wird nicht immer die beste Option sein.