Die Debatte über mobile Apps
Einführung
Mobile Apps und HTML5 sind derzeit zwei der angesagtesten Technologien und es gibt viele Überschneidungen. Webanwendungen werden in mobilen Browsern ausgeführt und können auch als native Apps auf den verschiedenen mobilen Plattformen umverpackt werden. Angesichts der breiten Palette von Plattformen, die unterstützt werden können, und der bloßen Leistung von mobilen Browsern nutzen Entwickler HTML5 als Lösung für das Schreiben einer, mehrere Ausführungen. Aber ist es wirklich rentabel? Es gibt immer noch überzeugende Gründe, native Designs zu entwickeln, und viele Entwickler gehen tatsächlich diesen Weg. In diesem Artikel geht es um Nativ im Vergleich zum Web.
Vielfältige Funktionen
Tipp: Native Anzeigen können mehr
Wir können die mobile Funktionalität in zwei Dimensionen unterteilen: die Erfahrung der App selbst und die Einbindung in das System des Geräts. Für Android wären dies beispielsweise Funktionen wie Widgets und Benachrichtigungen. Native Anzeigen eignen sich in beiden Dimensionen hervorragend.
Native Apps bieten in Bezug auf die Nutzerfreundlichkeit mehr. Sie können ganz einfach Swipe-Ereignisse, auch Mulitouch, für die Plattformen abrufen, die diese unterstützen. Sie funktionieren in der Regel beim Drücken fester Tasten, z. B. der Suchtaste und der Lautstärkeregelung von Android. Sie können auch auf Hardware wie GPS und Kamera zugreifen. Außerdem bieten einige Plattformen mit der Zustimmung des Nutzers uneingeschränkten Zugriff auf das Betriebssystem. Versuchen Sie, mit HTML5 den Akkustand zu ermitteln.
Aber es ist mehr als nur das In-App-Erlebnis. Ein Betriebssystem wie Android bietet verschiedene Möglichkeiten für Apps, mit Nutzern und in der Tat mit 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 haben Sie Intents, mit denen Ihre App einen allgemeinen Dienst bereitstellen kann, den andere Apps gelegentlich benötigen.
Kontrapunkt: Native Funktionen können erweitert werden und das Web holt sowieso auf
Es stimmt, dass viele In-App-Funktionen für HTML5-Apps einfach nicht ausreichen. Egal, wie heiß Ihre Web-Fu-Kenntnisse sind: Wenn Ihre App in einer Sandbox ohne Kamera-API festhängt, werden Sie so schnell keine Schnappschüsse machen! Zum Glück müssen Sie sich nicht in dieser Sandbox befinden. Wenn Ihre Webanwendung wirklich ein Foto machen soll, können Sie eine native Anwendung erstellen, eine mit einer eingebetteten Webansicht, die den Großteil der Benutzeroberfläche bietet. So funktioniert das Open-Source-PhoneGap-Framework: Es füllt die Lücke, indem native Funktionen als Webdienste verfügbar gemacht werden, die von der Webansicht über eine standardmäßige Netzwerk-API aufgerufen werden. Wenn Sie eine solche Hybridanwendung erstellen, können Sie auch diese Plattformfunktionen wie Widgets, Benachrichtigungen und Intents einbinden.
Die Entwicklung einer hybriden, also nativen und Web-App, ist kaum eine ideale Lösung. Sie erhöht die Komplexität und gilt nur für Webanwendungen, die als native Anwendungen verpackt sind, und nicht für herkömmliche Websites, die über einen mobilen Browser aufgerufen werden. Aber es wird vielleicht nicht lange notwendig sein. Webstandards ändern sich schnell und moderne mobile Browser gehen Schritt. So werden beispielsweise Offlinespeicher, Standortbestimmung, Canvas-Grafiken und Video-/Audiowiedergabe von vielen modernen Streaming-Geräten unterstützt. Sogar die Kamera wird nach und nach unterstützt. Seit Android 3.1 ist es möglich, Fotos und Videos mit Webstandards aufzunehmen. Außerdem unterstützt der neueste iOS-Browser WebSocket für 2-Wege-Streaming sowie die Erkennung der Geräteausrichtung.
Die mobile Welt entwickelt sich weiter. Das Web entwickelt sich jedoch schnell weiter. Unter den Desktop-Browsern allein gibt es fünf große Browser-Anbieter, die ihre Standards weiterentwickeln und blitzschnell neue Funktionen hinzufügen. Es ist zwar kein trivialer Prozess, diese Funktionen auf Mobilgeräte zu übertragen, doch viele von ihnen haben bereits ihren Weg in die mobilen Browser gefunden.
Native Anzeigen sind ein schnelllebiges Ziel, aber das Web schließt die Lücke.
Leistung
Punkt: Native Anzeigen werden schneller ausgeliefert
Bei systemeigenen Apps müssen die Weblaufzeiten nicht gelockert werden. Sie werden nah am Metal ausgeführt und können Leistungsoptimierungen wie GPU-Beschleunigung und Multithreading nutzen.
Kontrapunkt: Weblaufzeiten sind heute viel schneller und die meisten Apps benötigen sowieso keine Geschwindigkeit.
Es wäre untertrieben, zu sagen, dass das Web in den letzten Jahren schneller geworden ist. V8, die JavaScript-Engine, die im Lieferumfang von Chrome enthalten ist, war bei der Einführung eine bedeutende Weiterentwicklung der Webleistung und ist seitdem immer schneller geworden:
Auch Grafik-Rendering-Engines haben das Web beschleunigt, sodass jetzt die Hardwarebeschleunigung zunimmt. Werfen Sie einen Blick auf die Schwelle der Hardware Accelerated-Canvas:
Darüber hinaus ermöglicht die neue Web Workers API Multithreading. Moderne Webentwickler können außerdem auf eine Reihe leistungsoptimierter Bibliotheken und gut erforschte Techniken zur Leistungsoptimierung zurückgreifen. Die meisten davon waren anfangs auf dem Desktop-Web zu sehen, sind aber immer noch für Mobilgeräte relevant und der Schwerpunkt rückt zunehmend auf Mobilgeräte. So hat etwa der Leistungsguru Steve Souders eine Seite speziell für mobile Performance-Tools veröffentlicht.
Noch nicht alle Desktop-Fortschritte haben es auf jeder mobilen Plattform geschafft, aber die Trends deuten darauf hin, dass sie auf dem Weg sind. Wichtig ist auch, dass die meisten mobilen Apps keine bahnbrechenden 3D-Spiele sind, sondern im Wesentlichen informationsbasiert sind: Nachrichten, E-Mails, Fahrpläne, soziale Netzwerke usw. Rufen Sie einige Websites über Ihr Mobilgerät auf, z.B. Gmail, Amazon oder Twitter, und Sie können bestätigen, dass die Leistung des mobilen Webs mehr als angemessen ist. Für Spiele sind bereits einfache Spiele mit 2D-Canvas möglich und WebGL wird nach und nach auf Mobilgeräten angezeigt (siehe Firefox 4). Bis dahin gibt es eine wachsende Familie von Frameworks, die WebGL-Anwendungen zu nativen Anwendungen kompilieren, die OpenGL nutzen können, z.B. ImpactJS.
Entwicklererfahrung
Punkt: Native Anzeigen lassen sich einfacher entwickeln
Native Anwendungen nutzen robuste Programmiersprachen (z.B. Java, Objective C, C++), die für komplexe Anwendungsentwicklungen entwickelt wurden und sich bewährt haben. Die APIs wurden von Grund auf für die jeweilige Plattform entwickelt. Sie können ganz einfach Fehler in Anwendungen in Desktopemulatoren beheben, die eine enge Darstellung des Zielgeräts bieten.
Die Webentwicklung ist wegen der großen Vielfalt von Browsern und Laufzeiten besonders problematisch. Wenn Ihre Anwendung ausgeführt wird, ist nicht garantiert, dass Feature X verfügbar ist. Und selbst wenn ja, wie implementiert der Browser sie? Standards können interpretiert werden.
Konkret: Die Entwicklung des Webs ist häufig einfacher, insbesondere bei Ausrichtung auf mehrere Geräte.
Sprechen wir zuerst über die Kerntechnologie. Webstandards wurden ursprünglich in einer Zeit entwickelt, als es im Web vor allem um Dokumente und nicht um Apps ging, bei denen JavaScript in nur 10 Tagen erstellt und bereitgestellt wurde. Es hat sich jedoch als viel besser erwiesen als gedacht: Webentwickler haben gelernt, die guten Elemente zu nutzen und die schlechten Teile zu zähmen, wobei Muster für skalierbares Design jetzt bekannt sind. Darüber hinaus stehen die Standards nicht still und Prozesse wie HTML5, CSS3 und EcmaScript Harmony verbessern die Entwicklererfahrung. Ob Sie C++, Java oder JavaScript bevorzugen, ist eine religiöse Debatte und auch von Ihrer alten Codebasis abhängig. JavaScript kann heutzutage jedoch ein ernst zu nehmender Kandidat sein.
Der Nachteil der Browser-/Laufzeitfragmentierung besteht darin, dass alle diese Umgebungen überhaupt vorhanden sind. Wenn Sie eine Android-App in Java entwickeln, müssen Sie einen vollständigen Port für Objective C zur Unterstützung von iOS nutzen. Wenn Sie eine Webanwendung nur einmal entwickeln, kann sie unter Android und iOS ausgeführt werden, ganz zu schweigen von WebOS, BlackBerry, Windows Mobile und... na ja, das ist sowieso die Theorie. In der Praxis müssen Sie die Dinge für jede Plattform optimieren, wenn Sie wirklich die Anforderungen erfüllen möchten. Bei den meisten mobilen Betriebssystemen müssten Sie das jedoch auch in nativen Formaten tun, da es verschiedene Versionen und unterschiedliche Geräte gibt.
Die gute Nachricht ist, dass es im Web schon immer Fragmentierung gab und es bekannte Techniken gibt, damit umzugehen. Am wichtigsten ist jedoch, dass Entwickler aufgrund des Prinzips der progressiven Verbesserung zuerst auf ein grundlegendes Gerät abzielen und dort, wo verfügbar, plattformspezifische Funktionen hinzufügen können. Auch das Mantra der Featureerkennung ist hilfreich. Heutzutage bieten wir Bibliothekssupport von Modernizr, um responsives Webdesign zu unterstützen. Wenn Sie diese Techniken umsichtig einsetzen, können Sie Ihre Reichweite auf die meisten Geräte ausdehnen, selbst auf klassische „Feature-Phones“ und sogar auf Formfaktoren wie Smartwatches und Fernseher, unabhängig von Marke und Betriebssystem. Sehen Sie sich unsere Präsentation mit mehreren UIs auf der Google IO 2011 an, bei der wir verschiedene Formfaktoren (Feature-Phone, Smartphone, Tablet, Computer, Fernseher) mit einer gemeinsamen Codebasis aus Logik und Markup ausgewählt haben.
Look and Feel
Punkt: Native Anzeigen entsprechen dem Erscheinungsbild der Plattform
Eines der Hauptmerkmale jeder Plattform ist ihr Erscheinungsbild. Nutzer erwarten, dass Steuerelemente einheitlich dargestellt und auf die gleiche Weise bearbeitet werden. Es gibt bestimmte Redewendungen, die von Plattform zu Plattform variieren, z. B. was passiert, wenn ein Nutzer einen „langen Haltevorgang“ ausführt, d. h. ein Element mehrere Sekunden lang berührt? Plattformen haben Standardsprachen für solche Dinge und Sie können nicht alle mit einer einzigen HTML5-App zufriedenstellen.
Darüber hinaus wird das Erscheinungsbild der Plattform von der nativen Softwarebibliothek der Plattform orchestriert, deren Widgets das Erscheinungsbild enthalten, das die Nutzer erwarten. Allein durch die Verwendung des nativen Toolkits erhalten Sie einen Großteil des erwarteten Erscheinungsbilds „kostenlos“.
Gegenpunkt: Das Web hat sein eigenes Erscheinungsbild und du kannst die Weboberfläche auch für die Plattformen anpassen, die dir am wichtigsten sind.
Wie im vorherigen Abschnitt erläutert, wird bei der Webentwicklung eine einfache Version geschrieben, die für alle Zwecke geeignet ist, und diese dann schrittweise verbessert. Die Verbesserung basiert in der Regel auf Funktionen. Du kannst sie aber auch verbessern, indem du sie auf die Plattformen ausrichtest, die dir am wichtigsten sind. Dies ist eine Art „Browsererkennung“, die von der Web-Community manchmal missachtet wird, vor allem weil es so viele mögliche Browser gibt. Wenn Sie sich jedoch zwei oder drei Plattformen mit einer sehr hohen Priorität ansehen und bereit sind, sich zusätzlich zu den nativen Alternativen zu bemühen, ist dies die richtige Vorgehensweise.
Was die Basisversion anbelangt, hat das Web sein eigenes Erscheinungsbild. Wir können sogar sagen, dass jede mobile Plattform ein eigenes „Web-Erscheinungsbild“ hat, das durch den Standardbrowser und die Standardweblaufzeit festgelegt wurde. Ein „Web-Erscheinungsbild“ kann für Ihre Nutzer in Ordnung sein und ermöglicht Ihnen tatsächlich, ein höheres Maß an Konsistenz mit dem Browserverhalten auf Computern sowie mit denen auf anderen Geräten zu erzielen, mit denen der Nutzer möglicherweise arbeitet. Darüber hinaus gibt es viele erfolgreiche Anwendungen, die das native Design sowieso nur wenig unterstützen. Dies gilt sicherlich für Spiele (entspricht Ihr bevorzugtes mobiles Spiel dem Design Ihres mobilen Betriebssystems?) und sogar für konventionelle Anwendungen. Sehen Sie sich z. B. die beliebteren nativen Twitter-Clients auf der Plattform Ihrer Wahl an. Sie werden eine Vielzahl von Mechanismen für Benutzeroberflächen verwenden.
Auffindbarkeit
Punkt: Systemeigene Apps sind leichter zu finden
Mechanismen zur App-Bereitstellung wie der Android Market und der App Store von Apple sind in den letzten Jahren überwältigend beliebt und bilden eine wichtige treibende Kraft für die gesamte Mobilbranche. Jeder Entwickler kann seine native Anwendung an den Marketplace senden, wo Nutzer sie durch eine Kombination aus Suchen, Suchen und dem Abrufen von Empfehlungen finden können. Und nicht nur das: Wenn Sie Ihre Arbeit richtig gemacht haben, werden die großartigen Bewertungen und Kommentare die Nutzer davon überzeugen, auf die alles Wichtige Installationsschaltfläche zu klicken.
Gegenpunkt: Webanwendungen sind in der Tat leichter zu finden.
Das Web ist wohl das am besten auffindbare Medium, das jemals entwickelt wurde. Die einfache URL enthält (zumindest theoretisch) eine eindeutige Kennung für alles, was jemals im Web veröffentlicht wurde, einschließlich aller Apps, die auf Standardwebsites veröffentlicht wurden. Suchmaschinen machen es leicht zu erkennen, dass Inhalte und andere Websites darauf verweisen können. Dazu gehören auch Kataloge von Web-Apps, die mobilen Marktplätzen ähneln. Tatsächlich kann jede Person Web-Apps mit ihren Freunden teilen, indem sie in E-Mails und Nachrichten in sozialen Netzwerken darauf verlinken. Links können auch per SMS gesendet werden. Mobile Nutzer können auf den Link klicken und die App im Browser ihres Geräts starten.
Es gibt noch nicht dieselben Marktplätze, auf denen Nutzer Apps bewerten und kommentieren können, aber auch das ändert sich. Weiterlesen...
Monetarisierung
Tipp: Native Anzeigen können monetarisiert werden
„Eine 6-jährige Person stellt während der Mittagsstunde eine App her und verkauft eine Million Exemplare zu je 3 $“. Diese Überschrift wird heutzutage häufig verwendet. Daher ist es kein Wunder, dass sich große und kleine Entwickler auf den mobilen Marktplätzen für die Monetarisierung umsehen. Mobile Plattformen bieten Entwicklern mehrere Möglichkeiten, Apps direkt in Rechnung zu stellen. Am einfachsten ist die einmalige Zahlung, mit der die App für immer freigeschaltet werden kann. Auf einigen Plattformen werden auch In-App-Zahlungs- und Abomechanismen angeboten, die eng in einen einheitlichen, sicheren Mechanismus integriert sind. Diese neueren Zahlungsmittel ermöglichen es Entwicklern, eine erfolgreiche App in eine langfristige Einnahmequelle umzuwandeln.
Zusätzlich zu App-Zahlungen können Sie mit herkömmlichen Webmodellen wie Werbung und Sponsoring Einnahmen erzielen.
Kontra: Im Web war es schon immer möglich, Einnahmen zu erzielen, und die Möglichkeiten wachsen
Das Internet wäre nicht der Motor der modernen Branche, wenn es keine ausreichenden Einnahmemöglichkeiten gäbe. Obwohl sich direkte "Pay-per-Use"-Mechanismen noch nicht gut entwickelt haben, gibt es verschiedene Nischen, in denen abobasierte "Software as a Service"-Lösungen tatsächlich rentabel sind. Beispiele hierfür sind Google Apps, die Produktpalette von 37Signals und Premium-Versionen verschiedener E-Mail-Dienste. Darüber hinaus sind Direktzahlungen nicht die einzige Möglichkeit, von Webanwendungen zu profitieren. Dazu gehören Onlinewerbung, Affiliate-Links, Sponsorships, Cross-Promotions für andere Produkte und Dienstleistungen.
Für Webentwickler ist es völlig in Ordnung, die Schlagzeilen zu lesen und einen Hauch von Zahlungsneigung zu spüren. Sie können keine Web-URL an native Marktplätze senden. Was sollten Sie als Webentwickler tun? Dazu erstellen Sie eine native Wrapper-Anwendung. Erstellen Sie für jede Plattform, auf die Sie ein Targeting vornehmen möchten, eine leere native Anwendung, die einfach eine Webansicht enthält. In der Webansicht einbetten Sie die echte App ein. Sie reichen diese Apps dann einfach an die verschiedenen Marktplätze ein und sehen zu, wie die Einnahmen steigen. Heute gibt es auf den wichtigsten Marktplätzen wahrscheinlich Hunderte, wenn nicht Tausende Web-Apps, von denen einige so gerissen assimiliert wurden, dass wir ihre Web-Apps gar nicht kennen.
Der Nachteil ist die Last der Cross-Kompilierung für jede Plattform. Hier kommt ein bestehendes Framework wie PhoneGap ins Spiel. Noch besser: Es sind Webdienste wie PhoneGap Build und Apparatio in der Entwicklung. Verweisen Sie diese Websites auf Ihr Code-Repository. Daraufhin wird eine Android-App, eine iOS-App usw. angezeigt, die Sie bei den entsprechenden Stores einreichen können. Sie müssen keine nativen SDKs auf Ihrem Computer installieren. Zum Erstellen all dieser nativen Anwendungen brauchten Sie lediglich einen Codeeditor und einen Webbrowser.
Werden Web-Apps jemals direkt von den Marktplätzen unterstützt, ohne dass sie nativ umschlossen werden müssen? Es ist noch nicht klar. Wir wissen, dass Google den Chrome Web Store letztes Jahr eingeführt hat. Obwohl er nur für Desktop-Computer gilt, hat er Interesse bei anderen Browseranbietern geweckt und ist insgesamt Teil eines Trends zu Web-App-Katalogen, einschließlich einiger Versuche speziell für Mobilgeräte. Das Konzept eines Webshops steht noch am Anfang, aber die Anzeichen sind vielversprechend.
Ergebnisse
Es wäre schön, hier einen Gewinner anzugeben, aber im Moment gibt es noch keinen eindeutigen Gewinner. Einige Apps eignen sich am besten für native, andere am besten für das Web. Der Web-Stack hat wohl mehr Dynamik, aber was die Fähigkeiten und Ausführungsqualitäten betrifft, entwickeln sich auch native Anwendungen schnell. Und es sei denn, es kommt eine Zeit, in der Webtechnologien bei den meisten mobilen Betriebssystemen von höchster Priorität sind, spielen native Anzeigen immer eine wichtige Rolle.
Eine in diesem Artikel erwähnte Technik sind Hybridanwendungen. Für einige Entwickler ist dies möglicherweise der beste Kompromiss: Webansicht, wo es möglich ist, und plattformspezifische native Komponenten, wo dies nicht möglich ist.
Wenn Sie sich für den Webpfad entscheiden, beachten Sie die Webstandards und das Prinzip der Progressive Enhancement. Das Web ist eine Technologie, die auf eine Vielzahl von Geräten und Betriebssystemen ausgerichtet ist. Egal, ob Sie es als "Fragmentierung" oder "Vielfalt" bezeichnen, das Web akzeptiert es und Ihre Entwickler können von all dem bisher verfügbaren Verfahren profitieren.