Die Debatte um mobile Apps
Einführung
Mobile Apps und HTML5 sind derzeit zwei der wichtigsten Technologien und es gibt viele Überschneidungen. Web-Apps werden in mobilen Browsern ausgeführt und können auch als native Apps für die verschiedenen mobilen Plattformen neu verpackt werden. Angesichts der Vielzahl der zu unterstützenden Plattformen und der Leistungsfähigkeit von mobilen Browsern greifen Entwickler auf HTML5 als „einmal schreiben, überall ausführen“-Lösung zurück. Aber ist das wirklich machbar? Es gibt weiterhin gute Gründe, native Apps zu entwickeln, und viele Entwickler entscheiden sich auch dafür. In diesem Artikel geht es um die Frage, ob native Apps oder Web-Apps besser sind.
Funktionsumfang
Argument: Native Anzeigen bieten mehr Möglichkeiten
Die mobile Funktionalität lässt sich in zwei Dimensionen unterteilen: die Nutzung der App selbst und die Art und Weise, wie sie in das Ökosystem des Geräts eingebunden ist. Bei Android sind das beispielsweise Funktionen wie Widgets und Benachrichtigungen. Native-Anzeigen sind in beiden Dimensionen hervorragend.
Systemeigene Apps bieten mehr Möglichkeiten. Sie können ganz einfach Wisch- und Multitouch-Ereignisse für die entsprechenden Plattformen abrufen. Sie können in der Regel auf das Drücken von physischen Tasten reagieren, z. B. auf die Android-Suchtaste und die Lautstärkeregler. Sie können auch auf Hardware wie GPS und Kamera zugreifen. Mit der Erlaubnis des Nutzers bieten einige Plattformen uneingeschränkten Zugriff auf das Betriebssystem. Versuchen Sie einfach, den Akkustand mit HTML5 zu ermitteln.
Es geht aber um mehr als nur die In-App-Nutzung. Ein Betriebssystem wie Android bietet verschiedene Möglichkeiten für Apps, mit Nutzern und anderen Apps zu interagieren. Sie haben aktive Widgets auf der Startseite. Sie haben Benachrichtigungen, die in der Statusleiste des Geräts angezeigt werden. Außerdem gibt es Intents, mit denen Ihre App sich als Anbieter eines allgemeinen Dienstes ausgeben kann, den andere Apps gelegentlich benötigen.
Gegenargument: Native Funktionen können erweitert werden und das Web holt ohnehin auf
Viele In-App-Funktionen sind für eine HTML5-App einfach nicht möglich. Selbst wenn Sie ein Web-Guru sind, kann Ihre App keine Fotos aufnehmen, wenn sie in einer Sandbox ohne Kamera-API steckt. Glücklicherweise müssen Sie sich nicht in dieser Sandbox befinden. Wenn Ihre Web-App unbedingt ein Foto aufnehmen muss, können Sie eine systemeigene App mit einer eingebetteten WebView erstellen, die den Großteil der Benutzeroberfläche bereitstellt. So funktioniert das Open-Source-Framework PhoneGap: Es schließt die Lücke, indem es native Funktionen als Webservices bereitstellt, die von der Webansicht über eine Standard-Netzwerk-API aufgerufen werden. Wenn Sie eine solche Hybrid-App entwickeln, können Sie auch auf diese Plattformfunktionen wie Widgets, Benachrichtigungen und Intents zugreifen.
Eine Hybrid-App – nativ plus Web – ist kaum eine ideale Lösung. Es macht die Sache komplizierter und gilt nur für Web-Apps, die als systemeigene Apps verpackt sind, nicht für herkömmliche Websites, auf die über einen mobilen Browser zugegriffen wird. Aber das wird sich bald ändern. Webstandards entwickeln sich rasant weiter und moderne mobile Browser halten Schritt. Offline-Speicher, Geolocation, Canvas-Grafiken und Video-/Audio-Wiedergabe werden beispielsweise von modernen Smartphones umfassend unterstützt. Sogar die Kamera wird unterstützt – seit Android 3.1 ist es möglich, Fotos und Videos mit Webstandards aufzunehmen. Der aktuelle iOS-Browser unterstützt WebSocket für bidirektionales Streaming sowie die Erkennung der Geräteausrichtung.
Insgesamt entwickelt sich das mobile Internet weiter. Das Web entwickelt sich jedoch auch rasant weiter. Allein bei Desktopbrowsern gibt es fünf große Browseranbieter, die Standards weiterentwickeln und in rasantem Tempo Funktionen hinzufügen. Die Übertragung dieser Funktionen auf Mobilgeräte ist zwar nicht einfach, aber viele von ihnen sind bereits in den mobilen Browsern verfügbar.
Native-Apps sind ein schnelllebiges Ziel, aber das Web schließt die Lücke.
Leistung
Argument: Native-Apps sind schneller
Bei nativen Apps gibt es keine Web-Laufzeitbarriere. Sie werden nah an der Hardware ausgeführt und können Leistungssteigerungen wie GPU-Beschleunigung und Multithreading nutzen.
Gegenargument: Web-Runtimes sind heute viel schneller und die meisten Apps benötigen die Geschwindigkeit ohnehin nicht.
Es wäre eine Untertreibung zu sagen, dass das Web in den letzten Jahren schneller geworden ist. V8, die in Chrome enthaltene JavaScript-Engine, war bei ihrer Einführung eine wichtige Entwicklung im Bereich der Webleistung und ist seitdem nur noch schneller geworden:
Grafik-Rendering-Engines haben das Web ebenfalls beschleunigt und jetzt beginnt die Hardwarebeschleunigung. Hier sehen Sie ein Beispiel für eine solche „Geschwindigkeitsbegrenzung“ durch die hardwarebeschleunigte Canvas-Funktion:
Außerdem ermöglicht die neue Web Workers API Multithreading. Moderne Webentwickler können auch auf eine Reihe von leistungsoptimierten Bibliotheken und gut recherchierten Techniken zur Leistungsoptimierung zurückgreifen. Die meisten dieser Tools wurden für das Desktop-Web entwickelt, sind aber auch für Mobilgeräte relevant.Außerdem wird Mobilgeräten immer mehr Aufmerksamkeit geschenkt. So hat der Leistungsexperte Steve Souders eine Seite mit Tools zur Optimierung der Leistung auf Mobilgeräten erstellt.
Noch sind nicht alle Desktop-Innovationen auf allen mobilen Plattformen verfügbar, aber die Trends deuten darauf hin, dass sie bald kommen werden. Außerdem ist es wichtig zu wissen, dass die meisten mobilen Apps keine hochmodernen 3D-Spiele sind, sondern im Grunde informationsbasiert: Nachrichten, Mail, Fahrpläne, soziale Netzwerke usw. Wenn Sie einige Websites auf Ihrem Mobilgerät aufrufen, z.B. Gmail, Amazon oder Twitter, können Sie feststellen, dass die Leistung des mobilen Webs mehr als ausreichend ist. Was Spiele betrifft, so sind einfache Spiele bereits mit 2D-Canvas möglich, und WebGL wird langsam auf Mobilgeräten eingeführt – siehe Firefox 4. Bis dahin gibt es eine wachsende Familie von Frameworks, die WebGL-Apps in native Apps kompilieren, die OpenGL nutzen können, z.B. ImpactJS.
Für Entwickler
Argument: Native Apps sind einfacher zu entwickeln
Für native Apps werden robuste Programmiersprachen wie Java, Objective C und C++ verwendet, die für die Entwicklung komplexer Anwendungen konzipiert sind und sich bewährt haben. Die APIs wurden von Grund auf für die jeweilige Plattform entwickelt. Apps lassen sich ganz einfach in Desktop-Emulatoren debuggen, die das Zielgerät genau nachbilden.
Was die Webentwicklung besonders schwierig macht, ist die große Vielfalt an Browsern und Runtimes. Wenn Ihre App ausgeführt wird, ist nicht garantiert, dass Funktion X verfügbar ist. Und selbst wenn das der Fall ist, wie wird der Browser es implementieren? Standards sind offen für Interpretationen.
Gegenargument: Die Webentwicklung ist oft einfacher, insbesondere wenn mehrere Geräte als Zielgruppe infrage kommen.
Sehen wir uns zuerst die Kerntechnologie an. Webstandards wurden ursprünglich in einer Zeit entwickelt, in der das Web im Grunde nur aus Dokumenten bestand und nicht aus Apps. JavaScript wurde in nur 10 Tagen entwickelt und bereitgestellt. Sie haben sich jedoch als viel leistungsfähiger erwiesen als erwartet. Webentwickler haben gelernt, die guten Aspekte zu nutzen und die schlechten zu zähmen. Mittlerweile gibt es Muster für skalierbares Design. Außerdem entwickeln sich die Standards ständig weiter. Initiativen wie HTML5, CSS3 und EcmaScript Harmony verbessern die Entwicklerfreundlichkeit. Ob Sie C++, Java oder JavaScript bevorzugen, ist eine Glaubensfrage und hängt auch von Ihrer vorhandenen Codebasis ab. JavaScript ist heutzutage aber auf jeden Fall eine ernstzunehmende Option.
Die Kehrseite der Browser-/Laufzeitfragmentierung ist die Tatsache, dass es all diese Umgebungen überhaupt gibt. Wenn Sie eine Android-App in Java entwickeln, müssen Sie sie vollständig in Objective C portieren, um iOS zu unterstützen. Entwickeln Sie eine Web-App einmal und sie wird auf Android und iOS ausgeführt, ganz zu schweigen von WebOS, BlackBerry, Windows Mobile und… nun ja, das ist zumindest die Theorie. In der Praxis müssen Sie die Dinge für jede Plattform anpassen, wenn Sie wirklich ein gutes Nutzererlebnis bieten möchten. Das müssten Sie aber auch bei nativen Apps für die meisten mobilen Betriebssysteme tun, da es verschiedene Versionen und Geräte gibt.
Die gute Nachricht ist, dass die Fragmentierung im Web schon immer so war und es bekannte Techniken gibt, um damit umzugehen. Vor allem aber fordert das Prinzip der progressiven Verbesserung Entwickler auf, zuerst ein einfaches Gerät als Ziel zu definieren und dann plattformspezifische Funktionen hinzuzufügen, sofern sie verfügbar sind. Das Mantra der Funktionserkennung hilft ebenfalls. Heutzutage gibt es Bibliotheksunterstützung von Modernizr, um responsives Webdesign zu unterstützen. Wenn Sie diese Techniken sorgfältig einsetzen, können Sie die meisten Geräte erreichen, auch ältere Mobiltelefone und Formfaktoren wie Smartwatches und Fernseher, unabhängig von Marke und Betriebssystem. Auf der Google I/O 2011 haben wir eine Demo mit mehreren Benutzeroberflächen gezeigt, bei der wir mit einer gemeinsamen Codebasis für Logik und Markup auf verschiedene Formfaktoren (Feature-Phone, Smartphone, Tablet, Computer, Fernseher) ausgerichtet waren.
Erscheinungsbild
Punkt: Native Anzeigen passen zum Erscheinungsbild der Plattform.
Eines der wichtigsten Merkmale einer Plattform ist ihr Erscheinungsbild. Nutzer erwarten, dass Steuerelemente einheitlich dargestellt und auf dieselbe Weise bedient werden. Bestimmte Idiome variieren von Plattform zu Plattform, z.B. was passiert, wenn der Nutzer ein Element mehrere Sekunden lang berührt? Plattformen haben Standardausdrücke für solche Dinge, die Sie nicht alle mit einer einzigen HTML5-App erfüllen können.
Außerdem wird das Erscheinungsbild der Plattform von der nativen Softwarebibliothek der Plattform gesteuert, deren Widgets das Erscheinungsbild kapseln, das Nutzer erwarten. Sie erhalten viel von der erwarteten Benutzeroberfläche „kostenlos“, indem Sie das native Toolkit verwenden.
Gegenargument: Das Web hat sein eigenes Erscheinungsbild und Sie können die Weboberfläche auch für die Plattformen anpassen, die Ihnen am wichtigsten sind.
Wie im vorherigen Abschnitt erläutert, besteht die Vorgehensweise bei der Webentwicklung darin, eine grundlegende Version zu schreiben, die für alle Geräte geeignet ist, und diese dann schrittweise zu verbessern. Die Optimierung basiert in der Regel auf Funktionen. Sie können sie aber auch optimieren, indem Sie die Plattformen auswählen, die Ihnen am wichtigsten sind. Dies ist eine Art „Browsererkennung“, die von der Web-Community manchmal kritisiert wird, vor allem, weil es so viele verschiedene Browser gibt. Wenn Sie jedoch zwei oder drei Plattformen mit sehr hoher Priorität im Blick haben und bereit sind, den zusätzlichen Aufwand in Kauf zu nehmen, um sich gegen native Alternativen zu behaupten, ist dies möglicherweise der richtige Weg.
Was die Baseline-Version betrifft, so hat das Web sein eigenes Look-and-Feel. Man kann sogar sagen, dass jede mobile Plattform ihr eigenes „Web-Look-and-Feel“ hat, das durch den Standardbrowser und die Web-Laufzeitumgebung festgelegt wird. Das „Web-Look-and-Feel“ ist möglicherweise für Ihre Nutzer in Ordnung und ermöglicht Ihnen sogar eine größere Konsistenz mit der Desktop-Browserumgebung sowie mit anderen Geräten, mit denen der Nutzer möglicherweise arbeitet. Außerdem gibt es viele erfolgreiche Apps, die das native Erscheinungsbild ohnehin nicht unterstützen. Das gilt natürlich für Spiele (entspricht das Design Ihres Lieblings-Mobile Games dem Ihres mobilen Betriebssystems?) und sogar für herkömmliche Apps. Sehen Sie sich z. B. die beliebtesten nativen Twitter-Clients auf Ihrer bevorzugten Plattform an. Sie werden eine Vielzahl von Benutzeroberflächenmechanismen sehen.
Auffindbarkeit
Argument: Systeminterne Apps sind leichter zu finden
App-Verteilungsmechanismen wie der Android Market und der Apple App Store sind in den letzten Jahren sehr beliebt geworden und sind eine wichtige Triebkraft für die gesamte mobile Branche. Jeder Entwickler kann seine systemeigene App im Marketplace einreichen. Nutzer können sie dort durch Browsen, Suchen und Empfehlungen finden. Außerdem können Sie Nutzer mit positiven Bewertungen und Kommentaren dazu bewegen, auf die wichtige Schaltfläche „Installieren“ zu klicken.
Gegenargument: Web-Apps sind leichter zu finden
Das Web ist wohl das Medium, das am besten für die Entdeckung von Inhalten geeignet ist. Die bescheidene URL ist (zumindest theoretisch) ein eindeutiger Bezeichner für alles, was jemals im Web veröffentlicht wurde, einschließlich aller Apps, die auf Standardwebsites veröffentlicht wurden. Suchmaschinen erleichtern das Auffinden dieser Inhalte und andere Websites können darauf verlinken, einschließlich Katalogen von Web-Apps, die mobilen Marktplätzen ähneln. Tatsächlich kann jeder Einzelne Web-Apps mit seinen Freunden teilen, indem er einfach in E‑Mails und Nachrichten in sozialen Netzwerken darauf verlinkt. Links können auch in SMS gesendet werden. Mobile Nutzer können dann auf den Link klicken und die App im Browser ihres Geräts starten.
Derzeit gibt es noch nicht dieselben Marktplätze, auf denen Nutzer Apps bewerten und kommentieren können, aber das ändert sich auch. Weiterlesen…
Monetarisierung
Punkt: Native-Anzeigen können monetarisiert werden
„Sechsjähriger entwickelt in der Mittagspause eine App und verkauft eine Million Kopien für jeweils 3 $“. Diese Überschrift sehen Sie heutzutage oft. Es ist also kein Wunder, dass Entwickler, ob groß oder klein, auf den mobilen Marktplätzen nach Möglichkeiten zur Monetarisierung suchen. Mobile Plattformen bieten Entwicklern mehrere Möglichkeiten, direkt für ihre Apps abzurechnen. Am einfachsten ist die einmalige Zahlung, um die App für immer freizuschalten. Einige Plattformen bieten auch In-App-Zahlungs- und Abomechanismen an, die eng in einen einheitlichen, sicheren Mechanismus integriert sind. Mit diesen neueren Zahlungsmethoden können Entwickler eine erfolgreiche App in eine langfristige Einnahmequelle verwandeln.
Neben In-App-Zahlungen können Sie auch traditionelle Webmodelle wie Werbung und Sponsoring zur Monetarisierung nutzen.
Gegenargument: Die Monetarisierung im Web war schon immer möglich und die Möglichkeiten werden immer größer
Das Web wäre nicht der Motor der modernen Industrie, wenn es nicht viele Möglichkeiten gäbe, damit Geld zu verdienen. Obwohl sich direkte „Pay-per-Use“-Mechanismen noch nicht durchgesetzt haben, gibt es verschiedene Nischen, in denen abobasierte „Software as a Service“-Lösungen tatsächlich praktikabel geworden sind. Beispiele hierfür sind Google Apps, die Produktpalette von 37Signals und Premiumversionen verschiedener E-Mail-Dienste. Direktzahlungen sind jedoch nicht die einzige Möglichkeit, mit Web-Apps Geld zu verdienen. Dazu gehören Online-Werbung, Affiliate-Links, Sponsoring und Cross-Promotion für andere Produkte und Dienste.
Trotzdem ist es für Webentwickler durchaus nachvollziehbar, wenn sie die Schlagzeilen lesen und ein wenig Neid aufkommt. Sie können keine Web-URL an die nativen Marktplätze senden. Was können Webentwickler also tun? Sie erstellen eine systemeigene „Wrapper-App“. Für jede Plattform, die Sie ansprechen möchten, erstellen Sie eine leere systemeigene App, die nur ein WebView enthält. In die Webansicht betten Sie die eigentliche App ein. Anschließend reichen Sie diese Apps bei den verschiedenen Marktplätzen ein und hoffen, dass Sie damit Geld verdienen. Es gibt wahrscheinlich Hunderte, wenn nicht Tausende von webbasierten Apps auf den wichtigsten Marktplätzen. Einige von ihnen sind so geschickt integriert, dass wir ihre Web-Apps gar nicht kennen.
Der Nachteil ist, dass Sie für jede Plattform eine Cross-Kompilierung durchführen müssen. Hier kann ein vorhandenes Framework wie PhoneGap helfen. Noch besser: Es gibt Webdienste wie PhoneGap Build und Apparatio, die sich in der Entwicklung befinden. Verweisen Sie mit diesen Websites auf Ihr Code-Repository und schon erhalten Sie eine Android-App, eine iOS-App usw., die Sie in den jeweiligen Stores einreichen können. Sie müssen keine nativen SDKs auf Ihrem Computer installieren. Für die Entwicklung all dieser nativen Apps benötigen Sie lediglich einen Code-Editor und einen Webbrowser.
Werden Web-Apps auf den Marktplätzen jemals direkt unterstützt, ohne dass sie nativ verpackt werden müssen? Das ist noch nicht klar. Wir wissen, dass Google letztes Jahr den Chrome Web Store eingeführt hat. Obwohl er sich nur auf den Desktop bezieht, hat er das Interesse anderer Browseranbieter geweckt und ist insgesamt Teil eines Trends hin zu Web-App-Katalogen, einschließlich einiger mobilspezifischer Versuche. Das Konzept eines Webshops befindet sich noch in der Anfangsphase, aber die Zeichen stehen gut.
Zusammenfassung
Es wäre schön, wenn wir hier einen Gewinner küren könnten, aber im Moment gibt es keinen eindeutigen Gewinner. Einige Apps eignen sich am besten für native Apps und andere am besten für das Web. Der Web-Stack hat zwar mehr Dynamik, aber in Bezug auf Funktionen und Ausführungsqualität entwickeln sich auch native Apps rasant weiter. Solange Webtechnologien nicht auf den meisten mobilen Betriebssystemen gleichberechtigt sind, wird Native immer eine wichtige Rolle spielen.
Eine in diesem Artikel erwähnte Technik sind Hybrid-Apps. Dies ist möglicherweise der beste Kompromiss für einige Entwickler: Webview, wo es möglich ist, und plattformspezifische native Komponenten, wo es nicht möglich ist.
Wenn Sie sich für den Webpfad entscheiden, sollten Sie Webstandards und das Prinzip der progressiven Verbesserung berücksichtigen. Das Web ist eine Technologie, die weiß, wie sie die Vielzahl von Geräten und Betriebssystemen ansprechen kann. Ob Sie es nun „Fragmentierung“ oder „Vielfalt“ nennen, das Web ist darauf ausgelegt und Sie als Entwickler können vom gesamten Stand der Technik profitieren.