Der Erfolg der Hybrid-Apps

Wir haben in dieser Woche die allgemeine Verfügbarkeit von App Cloud, unseres zweiten großen Produktes, bekannt gegeben. Alles Wichtige darüber finden Sie hier. Im heutigen Blog-Beitrag schildern wir, warum wir dieses Produkt überhaupt gemacht haben.

Beginnen wir mit einigen etwas kontroversen Aussagen:

• Native Apps sind keine Modeerscheinung, im Gegenteil: Sie stehen erst ganz am Anfang.
• HTML5 bewirkt einen grundlegenden Wandel für die Art und Weise, wie Apps erzeugt werden. Allerdings nicht so, wie einige dies vorhergesagt haben.
• Apps und HTML5 sind die Zukunft unseres digitalen Universums.
• Apps sind ein Weg, kein Ziel. Und wir müssen in Lifecyles denken.

Warum sind diese Aussagen wahr? Ein kleines Quiz verrät es uns, denn was haben alle unten gezeigten Apps gemeinsam?

Die Lösung ist einfach: Es sind alles Hybrid-Apps, entwickelt mit plattformübergreifendem HTML5 und eingebettet in einen nativen Container. Sie wurden gerade nicht vollkommen neu in plattformspezifischen Sprachen wie Objective-C oder Java erstellt. Normalerweise können reine HTML5 Web-Apps nicht in App-Märkten wie dem iTunes App Store oder Google Android Market auftauchen – diese Apps allerdings schon, da sie einen nativen Wrapper haben. Solche Wrapper ermöglicht diesen Apps damit auch den Zugang zu nativen Funktionen wie Kamera, Mikrofon, Kontaktliste oder Mitteilungssystem, die für den Browser nicht erreichbar sind.

Kommt der HTML5-Vorteil?

Facebook entwickelte schon 2007 eine 100 Prozent native App für das iPhone, die Version für das iPad folgte aber erst im Oktober 2011. Die iPad-Version erschien damit zeitgleich mit der Neuauflage der iPhone-Version und einer neuen Android-Version, die alle auf diesem neuen hybriden Web/Native-Ansatz, bei dem der größte Teil der App in HTML5 geschrieben ist, basieren. Warum wurde dieser Weg gewählt? David Fetterman, Mobile Engineering Manager bei Facebook, fasste es bei seinem Vortrag auf der f8 im vergangenen Monat wie folgt zusammen:

„Alle unsere Entwickler sind gut in HTML. Nur wenige von ihnen sind wirklich gut in Objective-C und Android. Wir können unsere Web-Entwickler so in einigen Aspekten ebenso gut wie unsere kundenseitigen Entwickler machen.“

Es ist bezeichnend, dass Facebook, ein Unternehmen mit praktisch unbegrenzten Ressourcen, wegen der Knappheit an guten nativen Entwicklern seine Strategie für die Produktion von Apps ändert. Wenn Facebook schon nicht genügend Objective-C- und Java-Entwickler finden kann, wie soll dies ein Unternehmen mit wesentlich geringeren Ressourcen schaffen?

Netflix hat die gleiche Route eingeschlagen und die Umstellung auf HTML5 zur Produktion nativer App-UIs bereits vor über einem Jahr vollzogen. Das Unternehmen hat HTML5-basierte Hybrid-Apps für viele mobile Geräteplattformen, Smart-TVs, Spielekonsolen und andere Produkte der Konsumelektronik geliefert. Dieses neue Konzept wurde auch überzeugend dargestellt, in Vorträgen und durch Veröffentlichung detaillierter Dokumente, die Theorie und Umsetzung des Konzeptes und die hierdurch gelösten Probleme beschreiben.

Auch Microsoft hat das hybride App-Konzept übernommen und lieferte kürzlich neue Versionen seiner App Bing for Mobile aus, die mit HTML5 in einem nativen Container produziert wurde. Die Bemerkung, dass Windows 8 die Erstellung nativer Apps in HTML5 unterstützen wird, löste bei Microsoft-Entwicklern intensive Ängste aus und auch wenn es noch unklar ist, wie sich dieser HTML5-Vorteil (bzw. Nachteil für nervöse XAML-Kämpfer) in der Windows Phone-Umgebung darstellen wird, ist sein Kommen sehr wahrscheinlich.

Der hybride App-Ansatz lockt Investoren
Einige Firmenübernahmen der jüngsten Zeit zeigen, welche strategische Bedeutung der hybride App-Ansatz heute schon besitzt – denn nichts beweist Engagement besser als ein offenes Scheckbuch. So hat Adobe kürzlich mit Nitobi den Entwickler von PhoneGap gekauft. Aktuell vollzieht Adobe gerade eine Kehrtwende weg von Flash im mobilen Browser, um das Unternehmen wieder für die neue App-zentrische Welt fit zu machen. PhoneGap war ein früher Verfechter von Hybrid-Apps und ermöglichte es Web-Entwicklern, ihren HTML5-Code mit nativen Containern zu kombinieren. Adobe hofft vermutlich darauf, dass es als Eigentümer von PhoneGap seine natürliche Position als dominanter Tool-Anbieter für das nächste Jahrzehnt festigen kann. Es hätte für Adobe keiner Übernahme bedurft, um Tools für reine HTML5-Websites im Browser zu bauen. Das kann das Unternehmen ganz allein. Aber hybride Web-Apps benötigen deen Baustein des nativen Containers, um Apps mit den Fähigkeiten des Betriebssystems zu verbinden. PhoneGap füllt diese Lücke durch Herstellen der Verbindung zwischen HTML5 und der nativen App-Wirtschaft. Adobe hat sich also eine vernünftige Versicherung für das neue digitale Medienzeitalter eingekauft, und dabei sogar noch ein gutes Geschäft gemacht.

Auch die kürzlich erfolgte Übernahme der Talente von Strobe durch Facebook ist ein weiterer Beweis für die Bedeutung dieses neuen Konzeptes: Strobe wurde gegründet, um ein Geschäft um Spoutcore von Charles Jolley, herum aufzubauen – Spoutcore ist ein Open Source JavaScript-Framework zur Erzeugung von Touch-Web-Apps, das mit einem nativen Container zur Herstellung einer hybriden App kombiniert werden kann. Schon vor der Übernahme hatte Strobe mit der Entwicklung kommerzieller Cloud-Services für das kostenlose Framework begonnen. Als Teil von Facebook steht das Schicksal der Kerntechnologie und dieser Cloud-Services in den Sternen. Aber eines ist ganz klar: Facebook lässt Charles und sein Team an seiner App-Strategie arbeiten, und bei dieser Strategie geht es nur um die Erfahrung mit hybriden Apps.

Teure Entwicklung auf dem Weg zum App-Store
Eigentlich ist das Verrückte an diesem neuen hybriden App-Ansatz, dass die App-Wirtschaft ursprünglich ganz anders geplant war: Die ursprüngliche Vision von Apple für Apps zog eine klare Trennlinie zwischen Web-Apps und nativen Apps, offenbar in der Annahme, dass nativer Code das beste Ergebnis für die Endanwender und die besten Vermarktungschancen bieten würde. Beim Launch des ersten iPhones gab es auch noch keinen echten iTunes App Store. Die einzige Möglichkeit, das Gerät mit Anwendungen zu bestücken, war die Speicherung von Websites als Lesezeichen auf dem Home Screen. Man muss sich auch daran erinnern, dass dieser eingeschränkte Browser-zentrische Ansatz von der Apple-Entwickler-Community vielfach als unzureichend zurückgewiesen wurde und sie stattdessen lautstark nach anspruchsvollen Tools zur Entwicklung nativer Anwendungen verlangte. Im März 2008, 14 Monate nach dem ersten iPhone-Launch, stellte Apple dann auch schon ihr App SDK und den iTunes App Store vor. Der Rest ist Geschichte.

Auf Grund des unglaublichen Erfolgs und der damit verbundenen Eigendynamik lässt sich das native App-Konzept nicht mehr wegdenken. Trotzdem zeigen sich jedoch einige Alterserscheinungen. Denn zum Leidwesen aller hat sich die plattformspezifische Entwicklung nativer Apps als relativ kostspielig erwiesen. Das zeigt sich schon an den relativen Einkommen der Entwickler nativer Apps, die im Schnitt 28 Prozent mehr als Web-Entwickler verdienen (diese Zahlen wurden durch die Suche nach Stellenangeboten bei der Online-Technologie-Jobbörse Indeed.com ermittelt). Und dies ist sicherlich einer der Gründe, warum sich Facebook für hybride Apps interessiert.

 

Entwickler für native Apps sind nicht nur teurer und schwieriger zu finden, sondern sie außerdem auch hochgradig spezialisiert. Ihre Qualifikationen sind zu plattformspezifisch, was ein großes Problem darstellt, denn: Smart Phone-, Tablet- und sonstige CE-Plattformen vermehren sich schnell. Die derzeit relevantesten App-Plattformen sind iOS, Android, Blackberry, Windows Phone, Nokia QT, Samsung Smart TV, LG Smart TV, Panasonic Viera Connect und Sony Playstation Suite. Dabei werden Plattformen kommen und gehen, aber es wird nie die „eine“ geben – ob im mobilen Bereich oder bei CE-Produkten im Allgemeinen: An der Fragmentierungssituation wird sich nichts große ändern.

Man stelle sich nur vor, es müssten vollkommen separate Entwicklungsteams für IE, Chrome und Firefox besetzen werden – . Aber genau das spiegelt leider die aktuelle Situation wider, wie sie sich im Bereich digitaler Medien Managern und CMOs darstellt, die am Ende die Rechnung für die App-Produktion bezahlen müssen. Sie sind natürlicherweise dazu verpflichtet, eine größtmögliche Zielgruppe zu erreichen, wofür sie aber auf jeden Fall viele App-Plattformen unterstützen müssen und nicht nur eine einzige. Aktuell schauen sie nur auf einen riesigen Rückstau extrem teurer Projekte, die sich über eine Menagerie proprietärer Plattformen verteilen.

Erobert HTML5 den Markt?
Viele haben sich diese Situation angeschaut und gedacht „Hey, Moment mal, diesen Film kenne ich doch - die Lösung ist das offene Web!“ Diese Meinungsfraktion glaubt, dass native Apps eine flüchtige Modeerscheinung sind, eine Art schlechter Flashback in die Zeit der Enzyklopädien auf CD-ROMs, Compuserve und Microsoft Blackbird. Dazu kommen Vorhersagen zum „Ende von nativ“ und nostalgische Hoffnungen auf eine fröhliche Wiedergeburt der Browser, wenn reine HTML5-Apps native Apps verdrängen werden. Ich bin nachsichtig mit denen, die dies glauben, denn so schlecht ist die Story ja nicht – genau diese Entwicklungen haben wir ja bereits gesehen. Und HTML5 ist eine wunderbare Sache – sehen Sie sich nur die Kurve aus Indeed.com an, die das Vorkommen von HTML5 in den High-Tech-Stellenausschreibungen in den USA zeigt:

 

Offensichtlich steht hinter HTML5 ein starker Drive und definitionsgemäß bedeutet HTML5 die Zukunft des Webs – es wäre ziemlich verrückt, dagegen zu wetten. Trotzdem: Dies bedeutet nicht zwangsläufig, dass native Apps versagen müssen, damit HTML5 Erfolg hat. Und ebenso wenig bedeutet es, dass HTML5 alles kann oder alles leisten sollte.

**Eine unbequeme Pattsituation
**HTML5 wird häufig ganz treffend als „Schmerzapparat für Entwickler“ beschrieben, die sich tief in Entwicklungsbereichen, z.B. bei Spielen, bewegen, für die diese Technologie noch nicht ausgereift ist. Auch bei Anwendungen für Apps mit geringerem Content-Verbrauch kann HTML5 allein nicht alles leisten, was native Apps können. Meine aktuelle Scorecard sieht daher so aus:

Schon seit mehreren Jahren tobt im Web ein lächerlicher Streit über „native Apps“ vs. „Open Web“. Jüngste Beispiele für das Für und Wider in diesem Streit finden sich z.B. hier oder hier. Wie ich bereits an früherer Stelle schrieb, glaube ich, dass dies eine falscher Ansatz ist, da a) die Anwender gleich viel Zeit im Browser und in nativen Apps verbringen und b) mobile Web-Anwendungen und native Apps am besten für sehr verschiedene und dennoch komplementäre Phasen in einer Kundenbeziehung eignen: So lässt sich mit mobilem Web gut erstes Interesse erwecken, native Apps eignen sich hingegen optimal dafür, die Kundenbeziehungen zu pflegen. Es geht hier also nicht um ‚entweder/oder‘, sondern vielmehr um ein ‚sowohl als auch‘. Ich plädiere daher für eine friedliche Lösung in diesem Streit. Man sollte auch nicht ganz vergessen, dass – unabhängig davon, was die Welt für wünschenswert hält – Plattform-Eigentümer wie Apple, Google, Microsoft, Nokia, Samsung und andere die Richtung bestimmen: Sie legen derzeit aus (sicherheits-)technischen und kommerziellen Gründen die Grenzen dafür fest, was Browser-gehostete HTML5 Web-Apps leisten können.

Auch wenn sich die (sicherheits-)technischen Gründe im Laufe der Zeit wahrscheinlich durch neue Standards entschärfen lassen, wird es noch Jahre dauern, bis diese Änderungen die üblichen W3C-Bürokratie-Prozesse durchlaufen haben. Und noch viel länger wird es dauern, bis die neuen Standards in den Browsern der Endanwender umgesetzt werden.

Die wirtschaftlichen Gründe hinter der Beschränkung von HTML5 sind leider häufig struktureller und gewollter Natur, denn Aktionäre wollen z.B., dass Plattform-Anbieter lebendige und profitable native App-Wirtschaften kultivieren. Es wäre lächerlich darauf zu hoffen, dass marktbeherrschenden Kräfte gegen ihre eigenen Interessen handeln und ihre Plattformen durch das offene Web zum Gemeingut machen ließen – bei dieser Wette würde mit Sicherheit die Spielbank gewinnen. Die Plattform-Eigentümer lassen Hybrid-Apps in ihren App-Ökosystemen deshalb zu, weil sie diese immer noch kontrollieren können. Daran dürfte sich auch nichts ändern.

Wie steht es mit der Performance?
Manche Technik-Experten vertreten die Meinung, dass Apps auf der Basis einer HTML5-Webansicht, eingebettet in einem nativen Container, immer eine schlechtere Leistung aufweisen werden als reine native Apps. Wir glauben das nicht. Allein schon die Tatsache, dass die größten Unternehmen der Branche auf den hybriden Web/Native-Ansatz setzen, sollte genügen, um diese Vorstellung zu entkräften. Es wird sicherlich bestimmte Szenarien und Arten von Apps geben, bei denen HTML5 nicht funktioniert (denken Sie an den erwähnten Schmerzapparat), aber für eine Vielzahl von Content-zentrischen App-Implementierungen funktioniert ein gut optimierter HTML5-Code in Verbindung mit nativen APIs einwandfrei.

Wir sind die 99 Prozent
Branchengiganten wie Facebook, LinkedIn, Microsoft und Netflix sind ganz offensichtlich für die Erstellung von Apps zum neuen hybriden App-Ansatz übergegangen – Unternehmen also, die zwar nur 1 Prozent darstellen, aber mit ihren massiven Ressourcen die neueste Technologien nutzen und deren Weg zum Erfolg erzwingen können. Aber was ist mit dem Rest? Den 99 Prozent von Unternehmen, die Apps auf allen möglichen Plattformen wünschen und benötigen, aber nicht wissen, wie sie dies anstellen sollen? Bisher haben viele dieser restlichen 99 Prozent ihr Glück mit Apps versucht, indem sie eine Version 1.0 für einen einzigen Gerätetyp (z. B. iPhone) auf einer einzigen Plattform (z. B. iOS) entwickelt haben. Die Kunden, mit denen ich spreche, fragen sich aber, wie sie den nächsten Schritt bewerkstelligen sollen. Sie stehen unter dem Druck, ihre Apps auch für Android-Smartphones verfügbar zu machen. Und Tabletts. Und die Kindle Fire-Version von Android. Und XBox. Und PS3. Und Smart-TVs von Samsung. Und vielleicht auch Google TV.

Das ist natürlich eine anspruchsvolle Aufgabe, aber alle diese Plattformen haben bereits ein großes, attraktives Publikum oder dürften dieses in Zukunft haben. Auf ihre Bildschirme wird sich nicht nur die Aufmerksamkeit der Endanwender künftig richten, sondern sie werden auch die Werbegelder auf sich ziehen. Unternehmen, die ihre digitale Strategie ernst nehmen, müssen daher genau deshalb auch dort vertreten sein. Die Frage ist nur, wie lässt sich das bewerkstelligen. Der hybride App-Ansatz gehört definitiv als Teil zur Lösung dieses Problems. Er konzentriert die herausragende Effizienz und Agilität der Web-Entwicklung auf das App-Problem und liefert vielversprechende Resultate. Aber Apps sind mehr als nur eine von HTML5 abgeleitete schöne Fassade.

Apps sind ein Weg, nicht ein Ziel
Denn bei Apps kommt erschwerend hinzu, dass viele Unternehmen sie als diskrete, experimentelle, einmalige Entwicklungsprojekte ansehen, die oft an Subunternehmer mit Spezialkenntnissen vergeben werden. Sie konzentrieren sich auf die Benutzeroberfläche und denken relativ wenig an die Back-End-Administration und Content-Optimierung. Daher ist der Bedienablauf für nichttechnische kommerzielle Anwender und Content-Produzenten häufig schlecht strukturiert und es erfolgt keine Vorausplanung für Analytik und eine kommerzielle Nutzung. Es werden meist nur wenige bis gar keine Usability-Tests, geschweige denn dezentrale Betatests unter realen Bedingungen, durchgeführt. Auch Wartung, Versionsmanagement und End-of-Life-Strategie werden nicht planmäßig gehandhabt. Das Problem dabei: Dieses Verfahren ist sehr kurzsichtig und wenig Erfolg versprechend. Es ist vielmehr höchste Zeit, dass wir Apps als wertvolle digitale Güter betrachten, die sorgfältige Planung und Investition erfordern. Erfolgreiche Apps stellen nicht das Endziel dar, sondern sind Reisen durch einen Lifecycle, der viele verschiedene Rollen innerhalb eines Unternehmens und nicht nur die Entwickler betrifft. Selbst aktionsbezogene Apps für den einmaligen Gebrauch müssen aktiv gemanagt werden, sollen sie während ihrer kurzen Lebenszeit effektiv sein.

Entwickler und Architekten wertvoller App-Güter sollten über die Entwicklung markenspezifischer Vorlagen und Gerüsten nachdenken, mit denen sich neue Apps zeitsparend produzieren lassen. Für Websites gibt es dies bereits – warum also nicht auch für Apps? Genau wie auch Websites alle möglichen Datenoptimierungs- und Caching-Verfahren nutzen, sollte auch das für den Betrieb von Apps verantwortliche Team Back-End-Content-Quellen optimieren, um die Performance in mobilen Netzen mit hohen Latenzzeiten zu verbessern. App-Unternehmer und Werbetreibende sollten Analytik, Reporting und die Ausrichtung und Bereitstellung der Werbung genau wie bei Websites planen. Entwickler sollten kontinuierliche Tests in ihre Prozesse einbauen. Das gesamte Team sollte effiziente Verfahren zur Einführung neuer Versionen, zur Optimierung der Content-Präsentation und zur Abstimmung von Werbeaktionen festlegen.

Web-Teams müssen wieder Verantwortung übernehmen
Um Apps nachhaltiger und effizienter zu machen, müssen sie offensichtlich in einen proaktiv gemanagten Mainstream-Bereich gebracht werden, auch wenn man den frühen App-Pionieren natürlich schwerlich einen Vorwurf dafür machen darf, dass sie einfach die Abkürzungen genommen haben. Kompromisse müssen sein, wenn jedes App-Projekt auf neuester Technologie auf einer unbekannten Plattform basiert Denn diese Projekte werden oft an Entwickler außerhalb des traditionellen Web-Teams vergeben, so dass normale Regeln, Prozesse und Verantwortlichkeiten oft auf der Strecke bleiben.

Im gleichen Maße, wie Hybrid-Apps zum neuen Defacto-Standard werden, muss die Verantwortung für die Apps aber auch wieder in den Bereich des Web-Teams rücken, so dass Entwickler, Designer, Informationsarchitekten, Produzenten, Architekten, Front-End- und Back-End-Entwickler, DBAs, System-Administratoren und Projektmanager, die traditionelle Websites bauen und betreiben, wieder ins Spiel kommen. Denn genau ihre Fähigkeiten und Prozesse sind im Bereich der hybriden Web/Native-Apps von enormer Wichtigkeit.

Was wir dabei tun
Wir bei Brightcove verfolgen die hier angesprochenen Trends seit mehreren Jahren intensiv – und haben auch etwas dafür getan: Durch die Neuaufstellung unserer Video Cloud kann sie jetzt auf allen neuen Plattformen und Geräten eine gute Figur machen, und dies gilt sowohl in HTML5- als auch in nativen Umgebungen. Die jetzt allgemein verfügbare App Cloud ist eine neue Content-App-Plattform, die den gesamten Lifecycle Content-zentrischer Hybrid-Apps unterstützt. App Cloud kombiniert native Container mit HTML5, um die App-Produktion für Web-Entwickler schneller und einfacher zu machen. Mit App Cloud können auch technisch nicht versierte Anwender Apps erstellen, ohne Code schreiben zu müssen, und sie können diese sogar noch nach der Installation modifizieren, ohne dass Upgrades erforderlich sind. Nachdem eine App publiziert wurde, kann App Cloud die Content-Quellen und Bilder kontinuierlich managen und für mobile Umgebungen optimieren, so dass sie für den Endanwender zügig ablaufen. Darüber hinaus bieten wir mit App Cloud auch integrierte Analytik- und Kommerzialisierungstools an. App Cloud ist als eine durchgängige App-Plattform konzipiert, die den Geist des Webs in einem nativen App-Körper umsetzt.