In diesem Beitrag geht es hauptsächlich um die Vor- und Nachteile hybrider Web-Apps aus der Entwicklungsperspektive. Mit hybrid ist das aus der Anwendungsentwicklung bekannte Prinzip "Write once, compile anywhere" gemeint.
Native Apps benötigen für jedes Betriebssystem jeweils eine eigene Entwicklung. Hybride Apps werden in Html5, CSS3 und Javascript realisiert und benötigen für die Auslieferung an verschiedene Betriebssysteme (Android, iOS, Windows, ...) nur noch einen Betriebssystem-spezifischen Wrapper, der zudem automatisch generiert werden kann, z.B. mit Cordova, das früher bekannt war unter dem Namen PhoneGap.
Der Entwicklungsaufwand von hybriden Apps ist deshalb gegenüber dem für native Apps wesentlich geringer (vgl. Abb. 1).
Mobile Endgeräte basieren auf unterschiedlichen Betriebssystemen und Apps für diese Betriebssysteme werden in verschiedenen Programmiersprachen realisiert. So verwenden beispielsweise Android-Apps die Programmiersprache Java, während Apps für iOS (iPhone, ...) bevorzugt in der Programmiersprache Objective-C entwickelt werden.
Grundsätzlich lassen sich Apps für jedes Betriebssystem in jeder Programmiersprache realsieren. Allerdings werden vom Entwickler-Unternehmen (Google, Apple, Microsoft, ...) immer nur für eine Sprache System Development Kits (SDK) und sonstige wichtige Ressourcen für die Entwicklung zur Verfügung gestellt, so dass Entwicklern kaum eine Wahl bleibt.
Im Fall der nativen Apps führt dies zu erheblichen Entwicklungsaufwänden, will man seine Anwendung einer großen Zielgruppe zur Verfügung stellen, denn man kann nur in Ausnahmefällen davon ausgehen, dass sich die Zielgruppe nur für ein einziges Betriebssystem interessiert. Man benötigt dann für die wichtigsten Betriebssysteme (Android, iOS, Windows, ...) jeweils ein eigenes Entwicklerteam (vgl. Abb. 1).
Ein solches Entwicklerteam besteht aus Projektleiter, einigen Entwicklern und Interaktionsdesignern. Letztere lassen sich häufig Team-übergreifend einsetzen, aber trotzdem dürfte ersichtlich sein, dass die Investition in eine native App leicht die Millionen-€-Grenze übersteigt innerhalb einer kurzen Zeitspanne. Ein solches Projekt erhöht die Burn-Rate des Unternehmens erheblich. Oder, wie es dann in solchen Fällen vom Management manchmal etwas rustikaler formuliert wird: "Bei uns brennt die Hütte".
Eine native App ist also immer ein extrem hohes Investitionsrisiko, das man in Ausnahmefällen etwas reduzieren kann, wenn man sich z.B. entscheidet, eine App nur für iOS oder nur für Android anzubieten.
Grundsätzlich ist so etwas aber nicht zu empfehlen, da dann garantiert ein mehr oder weniger kleiner Teil der Kunden auf den Service einer mobilen Version verzichten muss.
Abb. 1: Vergleich der Projektaufwände für native und hybride Web-Apps
Die Wirtschaftlichkeit im Vergleich zu nativen Apps ist der Hauptgrund für die Entwicklung hybrider Apps. Man benötigt nur ein Team mit den Skills Html5, CSS3 und Javascript und schon ist man dabei.
Allerdings sollte man auch hier die Kosten und auch einige Nachteile nicht unterschätzen (vgl. Abb. 2).
Gegenüber einer statischen Webseite ist der Entwicklungs- und Testaufwand trotzdem höher, da alle mobilen Anwendungen erhöhte Anforderungen an das Layouten stellen und der Kommunikationsprozess zwischen Entwicklern und Interaktionsdesignern iterativer ist.
Es gibt grundsätzlich zwei Strategien für die Realisierung von hybriden Apps:
- hybride Apps plus Responsive Design und
- hybride Apps plus einem Framework für das UI (z.B. jQuery Mobile).
Die Performance ist bei hybriden Apps geringer als bei nativen, wobei die Alternative Hybride Apps plus Responsive Design etwas besser abschneidet.
Abb. 2: Verschieden Realisierungsansätze für mobile Web-Apps
Der Vergleich zeigt aber, dass man, wenn man als Unternehmen nicht gerade sehr viel Cash in der Kriegskasse hat, das man verbrennen kann, eine native App meist nicht in Frage kommt.
Ich sage bewußt "verbrennen". Aus Marketing-technischen Gründen wird man sich so etwas vielleicht leisten wollen nach dem Motte: "Wir als innovatives Unternehmen brauchen ein Vorzeige-Produkt / Projekt / etc.". Aber man muss sich klar machen, dass man wahrscheinlich kein Geld damit verdienen wird. Denn Apps werden heute verscherbelt wie früher Nippes-Ware in Kaugummiautomaten.
Nehmt ihr z.B. 4,99 € im iTunes-Store für eure App, die ihr früher als reine Desktop-Anwendung für 49 € verkauft habt, werdet ihr kaum noch Käufer finden. Nehmt ihr deshalb nur 70 Cent, nimmt Apple euch davon noch 30 Prozent ab und es bleiben euch 49 Cent übrig. Wenn ihr 1 Mio. Entwicklungskosten habt, könnt ihr euch ausrechnen, wieviele Apps ihr verkaufen müsst, um die Entwicklung zu amortisieren. Mal abgesehen von eurer starken OpenSource-Umsonst-Konkurrenz.
Die Rechnung "1/100tel des Preises der Desktop-Version, aber die 3- bis 4-fachen Personalkosten" wird nie aufgehen. Es sei denn, ihr seid überzeugt, dass eure Apps es im Ranking unter die ersten 5 schafft. Weltweit selbstverständlich. Der deutsche Markt reicht für eine Amortisation auch dann meist nicht.
Die Entwicklung einer hybriden App ist dagegen wesentlich risikoloser. Zwar muss man immer extremer Optimist sein, wenn man erwartet, einen Spitzenplatz in den Rankings zu ergattern. Gerade mit hybriden Apps dürfte dies gegenüber der Konkurrenz der nativen Apps wegen der schlechteren Performance aber schwierig sein.
Wer aber eine nicht allzu komplexe Webseite, z.B. ein Weblog, schon nach den Prinzipien des Responsive Designs gestaltet hat, für denn können unter günstigen Umständen die Kosten für die Realisierung einer hybriden Web-App fast gegen Null gehen.
Einen Online-Shop oder Anzeigenmarkt als hybride App plus UI-Framework (jQuery Mobile, etc.) zusätzlich zur statischen Desktop-Web-Version des Shops oder Anzeigenmarkts anzubieten, lässt sich ebenfalls wirtschaftlich und vom Ergebnis her vertreten, vorausgesetzt, man optimiert seine Anwendung von Beginn an in jeder Phase und jeder Hinsicht unter Performance-Aspekten.
Ausblick
In einigen der folgenden Beiträge wird ein Stack von Tools und Workflows vorgestellt, mit denen sich hybride Apps komfortabel realisieren lassen.
Minimalziel ist die Entwicklung einer App z.B. für das eigene Weblog. Dies geht im Prinzip mit nur einer einzigen Zeile selbst programmiertem Source Code. In der Praxis wird man noch etwas Zusatzarbeit leisten müssen, um ein benutzerfreundliches Ergebnis zu erzielen. Voraussetzung ist allerdings, dass das Weblog schon responsive ist.
In weiteren Artikeln wird dann gezeigt, wie man mit Netbeans, Cordova, jQuery Mobile und Drupal einen mobilen Online-Shop aufsetzen kann.