Wie schon in „Der bewegte Mann“ so treffend übersetzt: „Qua Vadis, Wo gehste?“ kann man sich die Frage stellen, wohin geht die Reise für hybride Apps.

Spätestens seit Mark Zuckerberg Ende 2012 in einem Interview auf der TechCrunch Disrupt sagte

„The biggest mistake we made as a company was betting too much on HTML5 as opposed to native, it… It’s just wasn’t ready.“

gab es Unruhe im Reich der “Hybriden Apps”. Andere Firmen, wie z. B. LinkedIn folgten.

Ausschlaggebend für die Diskussion war in erster Linie die Performance der HTML5-basierten Programmierung. Insbesondere komplexere Anwendungen (viele Aktionen wie anlegen, aktualisieren und löschen) waren von Seiten der Performance problematisch. Im Falle von facebook waren das z. B. Funktionen, wie das Nachladen von Informationen der Timeline beim Scrollen.

Aber ist das wirklich ein Problem? Für Firmen wie facebook, wo ein App schon fast ein Symbiose mit dem User eingehen muss :-), ja. Im Bereich der Unternehmensapplikationen sind sicherlich andere Aspekte relevant und nicht wie „smooth“ die Timeline nachgeladen wird oder über das Kippen des Endgeräts bestimmte Aktionen ausgeführt werden.

Das soll jetzt nicht heißen, dass Performance in einer Unternehmensapplikation vernachlässigt werden darf.

Die Performance hängt dabei von mehreren Faktoren ab. Zum einen (wenn wir auch nur den Zeitraum seit 2012 nehmen) hat sich die Performance der Hardware, also der Smartphones stetig erhöht. Wenn ich daran denke, dass jedes Smartphone meinen guten alten C64 in die Tasche steckt :-(…

Ein weiterer Aspekt ist der zugrundeliegende Browser der genutzt wird, somit also das unterliegende Betriebssystem (iOS, Android, Windows, …). Es ist natürlich klar, dass die Verarbeitung von HTML5 zu einem Großteil von der Verarbeitung durch den Browser abhängig ist. Da hybride Apps Webtechnologien nutzen, ist dieser Aspekt ein Wesentlicher! In diesem Zusammenhang ist ein spannender Punkt, auf welche Funktionen eines Smartphones heute bereits der Browser zugreifen darf.

Last but not least spielt auch die Softwareentwicklung eine große Rolle. Ob auf Server-Seite (z. B. node.js, Web-Socket-Technologie) oder auf Client-Seite (z. B. Ionic) ist hier ein stetiger Fluss, der die Nutzung von hybriden Apps erleichtert bzw. verbessert.

Wenn wir von der hedersoft jetzt mit Kunden über Anforderungen sprechen, die auf die Entwicklung einer mobilen Applikation hinauslaufen, ist es fast immer so, dass man zwei Aussagen antrifft:

  1. Es muss eine native App sein
  2. Es muss eine Web App sein

Hybride Applikationen stehen oftmals nicht im Fokus. Ob nur aus Unwissenheit oder aufgrund der Skepsis die man im Internet findet, sei an dieser Stelle unwichtig. Lustigerweise ist es so (sofern man bestimmten Studien glauben darf), dass rund 60% der mobilen Unternehmensapplikationen hybride Applikationen sind :-)…

Neben den Anforderungen an die App spielt natürlich auch die mobile Unternehmensstrategie eine Rolle:

Hat sich ein Unternehmen für einen Anbieter entschieden, z. B. nur Apple Endgeräte, so liegt natürlich die Annahme nah, auch eine native Applikation zu schreiben. Folgende Punkte sollte man aber beherzigen:

  • Technologien ändern sich. Wer hätte von einigen Jahren noch gedacht, dass Blackberry so in der Versenkung verschwindet.
  • HTML/Java/Javascript Entwickler sind oftmals im Unternehmen vorhanden bzw. kostengünstiger einzukaufen als Entwickler von nativen Applikationen
  • Benötige ich tatsächlichen vollumfänglichen Zugriff auf Hardwarekomponenten

Aber dieser „einfache“ Fall ist eher selten. In den meisten Fällen werden Smartphones mit unterschiedlichen Betriebssystemen genutzt. Sollte der Kunden (hoffentlich) keine BYOD Strategie verfolgen und eine Mobile Device Management Lösung nutzen, spricht gegen eine entsprechende Strategie auch nichts. Aber spätestens jetzt ist die Entwicklung von nativen Apps (hier wenden wir mal den Plural an) nicht mehr unbedingt sinnvoll, insbesondere wenn nicht nur iOS und Android sondern auch Windows-Mobile vorhanden ist!

Durch die Nutzung von HTML5 auf modernen Smartphones stellt sich somit die Frage, ob nicht eine Web-Anwendung die Anforderungen erfüllen kann. Dabei sind insbesondere die beiden Fragen „Offline-Fähigkeit“ und „Zugriff auf Hardwarekomponenten“ zu klären. Beides ist auch über eine reine Web-Anwendung möglich, jedoch mit Einschränkungen verbunden, wie Speicherplatz für Offlinenutzung oder auf welche Hardwarekomponenten darf der Browser zugreifen bzw. in welchem Umfang.

Sind diese Anforderungen für die Anwendung kein Thema, so kann eine reine Web-Lösung die richtige Antwort sein. Was ist aber, wenn sich in einer zukünftigen Version der Anwendung die Anforderungen ändern? Ist dann immer noch alles mit einer reinen Web-Anwendung umsetzbar?

Bin ich an diesem Punkt, sollte man sich den Lösungsansatz „Hybride App“ einmal genauer anschauen.

Die o. g. Nachteile der beiden anderen Varianten werden somit zu einem Großteil ausgebügelt. Ein Nachteil der hybriden Applikation ist, sofern man dies als Nachteil erachtet, dass ich ein „Framework“ benötigte, wie z. B. Titanium, PhoneGap oder Apache Cordova. IBM Worklight nutzt u. a. Apache Cordova, wenn mit Worklight eine hybride Applikation erstellt werden soll.

Des Weiteren sind die installierbaren Packages weitaus größer als z. B. bei einer nativen Applikation. Moderne MDM-Lösungen bieten jedoch die Möglichkeit, eine Applikation ohne Nutzung des App-Stores (z. B. Play Store von Google) zu installieren, so dass dieser Aspekt oftmals auch vernachlässigt werden kann.

Ich möchte mit diesem Beitrag nicht den Eindruck erwecken, dass hybride Applikationen die Antwort auf alle Fragen sind, jedoch ist der Ruf von hybriden Apps sicherlich nicht so schlecht, wie oftmals dargestellt.

Nichtdestotrotz kommt man als Unternehmen nicht darum herum, im Vorfeld eine genaue Analyse durchzuführen, welche Methodik für das Unternehmen und für die zu entwickelnde App geeignet ist.

Nochmals ein kurzer Überblick:

Bei der Entwicklung einer mobilen Applikation sind immer drei Vorgehensweise möglich:

  • Native App (Entwicklung erfolgt auf Basis des zugrundeliegenden Betriebssystems)
  • Web App (Entwicklung einer reinen Browserapplikation)
  • Hybride App (Entwicklung nutzt native Elemente in einem Browser-Container)

Dabei sind die folgenden Entscheidungskriterien zu berücksichtigen:

  • Performance
  • Offline Nutzbarkeit
  • Zugriff auf native Funktionen
  • Installation und Zurverfügungstellung auf den Endgeräten
  • Entwicklungskosten und Zeit
  • Testkosten und Zeit
  • Plattformunabhängigkeit

Die nachfolgende Abbildung zeigt die Stärken und Schwächen nochmals im Überblick. Für eine Analyse hilft es natürlich nicht, die einzelnen Stärken und Schwächen zu addieren. Wie mehrmals erwähnt, muss sowas immer im Kontext gesehen werden:

blog01_plusminus_apps

Ich hoffe, dass der Beitrag dem einen oder anderen helfen kann, um eine Entscheidung treffen zu können. Von Seiten der hedersoft stehen wir natürlich gerne auch beratend zur Seite!

Ach ja:

facebook scheint wohl zu der Erkenntnis gekommen zu sein, dass die reine Entwicklung von nativen Applikationen auch nicht das Gelbe vom Ei ist. Auch facebook versucht jetzt durch ein eigenes Framework native Applikationen zum Großteil über JavaScript zu entwickeln. Dazu wurde das Projekt „React Native“ ins Leben gerufen (basierend auf dem bereits bekannten Web-Framework „react.js“).

In der Keynote der React.js Conf 2015 werden die Hintergründe dazu einmal erläutert.

Ich selbst habe meinen facebook-Account zwar nach den letzten Änderungen der AGBs „gelöscht“, aber als hedersoft haben wir uns erstmal für das Beta-Programm angemeldet. Mal schauen, was „React Native“ wirklich kann. Die ersten Reaktionen im Netz sind recht positiv…