25 Native App oder Web App?

Native App oder Web App?

 

Fabian Kern

Die Grundfrage für Verlage und Buchhandlung ist doch immer, ob sich denn Apps rechnen können? Ein Produkt für 0,79 Euro muss man schon sehr oft verkaufen, wenn man rentabel sein möchte. Aber als Werbeinstrument kann es sehr sinnvoll sein, auf Apps zu setzen. Reichweite und Kundenbindung sind dann gefragt

Dann folgt die nächste Frage: Soll ich nur auf Apple setzen, auch auf Android und Windows oder nur auf das Web und den eigenen Shop? Will ich denn so abhängig sein von Apple und kann ich denn die Aufwände für Apps nicht auch gleich für andere Angebote nutzen? Jeder der Ansätze hat Vor- und Nachteile und lässt sich mit dem Schlagwort “Native App vs. Web App” umschreiben. Um die Diskussion zu erleichtern, kommt man um einen Blick auf die technologischen Hintergründe nicht herum.

Kriterien für Native App vs. Web App

Beginnen wir mit einer kurzen Definition der beiden App-Typen anhand einiger gängiger Modelle und Paradigmen, die in der modernen Software-Entwicklung verwendet werden:

Entwicklungssprache und Laufzeitumgebung

Native Apps werden in einer der Entwicklungsumgebungen und Programmiersprachen geschrieben, die das jeweilige App-Ökosystem zur Verfügung stellt, also: X-Code/Objective-C für das Apple Mobil-Betriebssystem iOS, Android IDE/Java für das Google Mobil-Betriebssystem Android und Visual Studio/.NET/C# für das Microsoft Mobil-Betriebssystem Windows Phone 7; Resultat ist eine kompilierte, lauffähige Anwendung, die direkt im Betriebssystem des Mobilgerätes ausgeführt wird.

Web Apps werden unter Verwendung von HTML/CSS zur Gestaltung der Bedienungsoberfläche erstellt, die Funktionalitäten in Javascript implementiert, das mit geeigneten Schnittstellen in den HTML-Code eingebettet wird. Resultat ist eine Anwendung, die einen Browser (Windows Explorer, Mozilla Firefox, Apple Safari, Google Chrome, etc. – und insbesondere dessen Javascript-Engine) als Laufzeit-Umgebung benötigt. Da jedoch jedes Mobil-Betriebssystem mindestens einen Standard-Browser als eine eigene Native App mitbringt (die in der Regel eng mit dem Ökosystem verzahnt ist), bedeutet dieses Aufsetzen auf einen Browser in der Praxis keine wirklich relevante Einschränkung.

Client/Server-Model

Beschreibt man eine Anwendung als zweischichtiges Model aus einem Client, in dem Präsentation und Nutzer-Interaktion erfolgt, während der Server Datenspeicherung und Berechnung ausführt, dann laufen bei einer Native App Client und Server innerhalb derselben Hardware- und Software-Umgebung, d.h. im lokalen Speicher des Mobilgerätes ab. Bei einer Web App ist die Zweiteilung quasi „vorprogrammiert“: Der Client wird im Browser ausgeführt, der Server ist ein an beliebigem Ort ausgeführter Webserver. Der Webserver kann allerdings bei entsprechender Konfiguration auch als lokal ausgeführter Dienst gestaltet werden.

3-Schichten-Model

Während die Client/Server-Aufteilung ein rein technisch motiviertes Paradigma ist, lehnt sich das 3-Schichten-Model an Design und Entwurf einer Anwendung an. Als drei verschiedene Schichten werden Oberfläche/Nutzer-Interaktion, Geschäftslogik/Funktionalität und Datenspeicherung/Kommunikation unterschieden. Nach diesem Modell lassen sich die Unterschiede von Native App und Web App folgendermaßen charakterisieren:

Native App

  • Oberfläche: Native Oberflächen-Komponenten/Bedienelemente der jeweiligen Entwicklungsumgebung,
  • Geschäftslogik: Programm-Bibliotheken in Objective-C, .Net/C#, Java; direkter Zugriff auf Betriebssystem-Schnittstellen,
  • Speicherung und Kommunikation: Speicherung in lokalen Datenbanken und Dateisystemen; Kommunikation über die Input/Output-Bibliotheken der jeweiligen Umgebungen.

Web App

  • Oberfläche: Oberflächen-Gestaltung komplett in Kombination von HTML, CSS, Javascript,
  • Geschäftslogik: Programm-Bibliotheken in Javascript; Zugriff auf Betriebssystem-Funktionen nur über Browser-Schnittstellen möglich,
  • Speicherung und Kommunikation: Speicherung in Webspace, oder Nutzung der lokalen Speicherung des Browsers (Cache, SQL-Datenbank, Offline-Dateisystem); Kommunikation über HTTP als Web-Protokoll.

Entscheidungskriterien für Native Apps vs. Web Apps

Soweit zunächst zu den Basistechnologien. Mit welchen Themen muss ich mich jedoch bei der Umsetzung realer Produktideen auseinandersetzen, wenn ich statt einer Nativen App auf das Entwickeln einer Web App mit HTML5-Technologien setze?

  • Oberflächen-Gestaltung:
    Die Verwendung von HTML/CSS bei der Web App zum Design von Bedienelementen und User-Interaktion schränkt den Entwickler auf die Gestaltungsmöglichkeiten dieser Standards ein. Die Anmutung einer nativen Anwendung und die Einhaltung der Bedienkonventionen und Empfehlungen der Ökosystem-Anbieter zu erreichen, bedeutet mit Web-Techniken höheren Aufwand. Auf der anderen Seite gewinne ich die Chance auf ein Anwendungsdesign, das sich mit relativ geringen Modifikationen auf verschiedenste Display-Größen und Proportionen verschiedener Hardware-Plattformen übertragen lässt.
  • Geschäftslogik:
    Implementiere ich bei der Web App den Funktionskern der Anwendung mit Javascript, dann verwende ich eine Sprache, die immer durch die Script-Engine des Browsers interpretiert und in nativen Betriebssystem-Code übersetzt werden muss, bevor sie ausgeführt wird. Die daraus resultierenden Performance-Unterschiede sind ein unbestreitbarer Faktor, dürften allerdings in der Praxis nur bei extrem rechenintensiven Operationen (z.B. 3D-Grafik, Datamining-Funktionen u.ä.) für den Nutzer wirklich spürbar sein. Deutlichere Einschränkungen für eine Web App ergeben sich, wenn für die Anwendung die Nutzung von gerätespezifischer Hardware notwendig ist, z.B. GPS-Modul oder Bewegungssensor/Gyroskop. Da für diese Hardware in der Regel keine Standard-Schnittstellen für eine Browser-Anwendung (und damit für eine Web App) zur Verfügung stehen, sind funktionale Anforderungen auf dieser Ebene oft (noch) ein k.o.-Kriterium gegen eine Web App.
  • Speicherung und Verfügbarkeit der Anwendung:
    Während eine Native App in der Regel alle Daten enthält, die sie zur Ausführung benötigt, sind vom Modell her bei der Web App die Daten stets in einem Web Space gespeichert. Ist Verfügbarkeit ohne Online-Verbindung jedoch eine zentrale Anforderung an die App, lässt sich das Modell in der Web App jedoch durch zwei zentrale Neuerungen in HTML5 ergänzen: Mit dem sogenannten „Local Storage“ kann ein Browser sowohl Daten in lokal gehaltenen SQL-Datenbanken speichern (z.B. Nutzereingaben, Zustände der Anwendung, Stammdaten/Bewegungsdaten bei Anwendungen mit komplexer Geschäftslogik) als auch nahezu beliebig Content wie HTML-Seiten, Bilder, Audio/Video lokal in seinem Cache halten und wieder aufrufen. Nutzt man die Möglichkeit des „Offline Browsing“, bietet HTML5 für eine Web App einen einfachen, generischen Mechanismus, um bei Aufruf einer Online-Seite gleichzeitig alle Dateien lokal abzulegen, die notwendig sind, um die Seite voll funktional auch ohne Online-Verbindung anzeigen und ausführen zu können. Die einzige Limitierung dabei besteht darin, dass jede Funktion zur Client/Server-Kommunikation so programmiert sein muss, dass sie im Notfall auch ohne Server sinnvoll ausgeführt werden kann.

Die hier als Beispiel beschriebene SPIEGEL-App ist diesen Weg bei der Implementierung bewusst nicht gegangen, ohne dass über die Gründe dafür mehr als spekuliert werden kann – dies heißt aber nicht, dass die Nutzung von Offline-Browsing bei einer Web App nicht für viele Anwendungsfälle technisch machbar und sinnvoll ist. Auf der anderen Seite greifen viele Native Apps zum Beispiel für große Content-Mengen (insbesondere z.B. Video-Content mit seinem immensen Dateigrößen) zum Hilfsmittel der Speicherung in einem Web Space und streamen den Content bei Bedarf in die Anwendung, um den Download einer App beim Kauf in einer Shop-Plattform zu verkleinern, integrieren also ein zentrales Design-Merkmal einer Web App in ihr Anwendungsmodell.

Welcher Ansatz ist für welchen Zweck?

Durch die fortschreitenden Technologien im HTML-Umfeld stellt sich natürlich relativ schnell die Frage: Wenn die Verwendung von HTML5-Techniken bei der App-Programmierung so viele Vorteile bringt, warum sollte ich dann überhaupt noch über native Entwicklung nachdenken? Warum soll ich Apple 30% überlassen und aufwändige Testings für die verschiedenen Android-Betriebssysteme durchführen? Die Antwort ist einfach: Weil es durch die genannten Eigenheiten und funktionalen Möglichkeiten der beiden Ansätze einzelne Schwerpunkte in Anforderungen an eine Anwendung gibt, für die der Web-Ansatz oder der Native-Ansatz besser oder schlechter geeignet ist.

Anwendungsmerkmale, die sich besonders für Native Apps eignen

  • Fancy User-Interfaces:
    Bedienungsoberflächen mit aufwändiger grafischer Gestaltung und/oder enger Verzahnung der Bedienelemente mit einer Geschäftslogik, die sich schwer in Javascript-Bibliotheken ausdrücken lässt. Eine Anwendung wie GarageBand zum Beispiel, dessen komplette Oberfläche aus der Anmutung von Musikinstrumenten wie Klaviatur, Gitarren-Griffbrett o.ä. besteht, wäre mit Mitteln von HTML/CSS und damit als Web-App nur mit immensem Aufwand überhaupt gestaltbar und darin alles andere als effizient.
  • Nutzung von spezifischen Hardware-Komponenten:
    Überall dort, wo die individuellen Gerätemerkmale wie GPS-Modul, Kameras, Mikrophone, Lagesensor/Gyroskop u.v.m. für zentrale Funktionen der Anwendung verwendet werden, ist eine native Programmierung (noch) fast unersetzbar. Eine Anwendung wie die 3D-Sternenkartemit ihrer Kombination aus aufwändiger Bedienoberfläche, die funktional direkt mit dem Gyroskop verzahnt ist, ist zur Zeit de facto nur mit einer Native App realisierbar.
  • Performancekritische Funktionen:
    Jede Anwendung, deren Funktionskern auf rechenintensive Operationen angewiesen ist, wie z.B. bei der Visualisierung von 3D-Grafik wie bei den meisten aufwändig gemachten Gaming-Anwendungen, dürfte sich momentan noch ausschließlich in nativen Umgebungen umsetzen lassen.

Anwendungsmerkmale, die sich besonders für Web Apps eignen

  • Straightforward User-Interfaces:
    Es eignen sich vor allem Bedienungsoberflächen, die sich vor allem auf die Zusammenfassung, Präsentation und Navigation innerhalb von in sich statischem Inhalten beschränken, und für die die Gestaltungsmittel einer Website ausreichend sind. Für viele Applikationen aus dem Medienbereich dürfte dieses Kriterium zutreffen, unabhängig vom dominanten Medientyp (Text, Audio, Video).
  • Einfache Geschäftslogik:
    Wenn Anwendungen gefragt sind, die keine aufwändigen Programm-Bibliotheken für ihre Funktionalität benötigen (wie es z.B. bei einer Steuererklärungs-Software oder anderen Productivity-Anwendungen mit eigenem „Rechen-Kern“ der Fall wäre), bietet sich die Implementierung in Javascript an, da die gegebenen funktionalen Einschränkungen hier wenig bis gar nicht zum Tragen kommen. Also auch hier: Das Darstellen von Texten, Videos und Audios stellt eben keinen hohen Anspruch an Geschäftslogiken dar und kann daher relativ simpel als Web-App programmiert werden.
  • Notwendigkeit zu hoher Aktualisierungsfrequenz:
    Wenn das Service-Modell einer Anwendung dauernde Content-Aktualisierung bedingt, bietet sich eine Web-App geradezu an, da der Update-Mechanismus für diesen Fall praktisch “mitgeliefert” wird bzw. auf einfache Weise in den Programm-Code integriert werden kann, während die Veröffentlichung und Distribution eines Programm-Update wie bei einer Native App mit erheblichem organisatorischen und zeitlichen Aufwand verbunden ist – was jeder weiß, der sich einen Programm-Update für seine Apps im Appstore herunter lädt.
  • Sammlung von Kundendaten:
    Will ich für meine Anwendung Nutzerdaten sammeln, und sei es nur auf der Ebene anonymisierter Erhebung der Nutzungshäufigkeit einzelner Content-Bereiche, bietet sich eine Web-App ebenfalls an, da die Datensammlung und das Reporting in der Regel bereits eine Standard-Funktion des Webserver im jeweiligen Webspace darstellt oder auf einfache Weise durch Zusatzmodule realisierbar ist.

In einer vergleichbaren Native App müsste jede Interaktion auf dieser Ebene einzeln und explizit implementiert werden. Der Unterschied zwischen Web App und Native App ist also auf technischer Ebene deutlich kleiner als er aufgrund der extremen Ausprägungen in konkreten App-Implementierungen zunächst erscheint.

Die Modelle werden zunehmend durchlässiger, zwischen den beiden App-Typen entwickelt sich eine breite Grauzone, bei der die präzise Unterscheidung der Typen zunehmend schwierig und wenig sinnhaft wird. Die Entscheidung für die Entwicklungspfade Web App oder Native App sollte sich im Idealfall danach richten, welche Funktionen die Anwendung im Detail bedienen soll, und welche der Eigenschaften der beiden App-Typen sich dafür mehr oder weniger eignet.

Im besten Fall wird sich in den nächsten Jahren eine Art „App-Typologie“ entwickeln, die als Entscheidungshilfe für den konkreten Business Case dienen kann. Insbesondere für Verlage und Medienunternehmen ist jedoch der Entwicklungspfad Web App sehr interessant und vielversprechend, da die naheliegenden Anwendungsmodelle in so starkem Maße ihren funktionalen Schwerpunkt auf der Präsentation von statischem Content haben, dass Web Apps ihre Vorteile in besonderem Maße ausspielen können.

Welche Kombinationen sind möglich – und was ist dafür zu tun?

Web App und Native Appsind keine vollständig separate Entwicklungspfade, die sich gegenseitig ausschließen, und die insbesondere bei der Wahl des Web-App-Modells eine Vermarktung über einen der App Stores ausschließen. Da die Nachteile einer ausschließlichen Eigenvermarktung durch die Haus-interne Plattform auf der Hand liegen und eben auch im o.g. SPIEGEL Artikel angerissen wurden, kann dieser scheinbare Widerspruch von Web-App und Native App durch deren Verknüpfung bzw durch die Integration einer Web-App in eine Native App aufgelöst werden. Heraus kommt dabei: Die Hybrid-App.

Integration einer vorhandenen Web App in eine Native App in fünf Schritten

  1. Entwicklung einer eigenen Native App, die nur mehr oder weniger aus einer einzigen Funktion besteht: Sie ruft ein displayfüllendes Browser-Fenster auf, prüft dabei, ob eine Online-Verbindung besteht (fängt den Offline-Fall dabei natürlich sinnvoll ab), und weist den Browser gleichzeitig an, den gesamten Content des Webspace in seinen local storage zu übernehmen.
  2. Idealerweise verbindet sich die Authentifizierung, die aus Sicherheitsgründen beim Aufbau der Verbindung erfolgen sollte, mit einer Identifikation des Kunden auf der haus-internen Online-Plattform.
  3. Im Web-Space müssen einige Vorkehrungen und Konfigurationen erfolgen, damit der Offline-Browsing-Mechanismus wirken kann. Dies kann jedoch auf vergleichsweise triviale Weise erfolgen.
  4. Durch das Hinzufügen alle notwendigen Komponenten für Oberfläche und Vermarktung bei der Native App entsteht ein vollwertiges Shop-Angebot für einen App-Store , d.h. inkl. Anwendungs-Icons, Anwendungsname, Werbetexte, etc.
  5. Die resultierende Native App – als „Brückenlösung“ für die vorhandene Web-App – ist dann ebenso für den Shop-Verkauf in den App-Stores geeignet, als wenn die Web-App zu 100% in der nativen Entwicklungsumgebung programmiert worden wäre.

Das hier skizzierte Vorgehen funktioniert in den Grundzügen bereits, wenn man es als Entwickler komplett „zu Fuss“ erledigt, d.h. alle notwendigen Programmcodes und Konfigurationen dafür selber erstellt. Der Ansatz lässt sich jedoch noch deutlich beschleunigen, wenn dazu optimierte Programmier-Frameworks verwendet werden, für die sich im Moment ein lebendiger Markt entwickelt.

Als ein Beispiel von vielen sei hier PhoneGap genannt: Ein Framework, das ausschließlich auf den Zweck ausgelegt ist, den Graben zwischen Web-App-Programmierung und Mobilbetriebssystemen mit hohem Automatisierungsgrad effizient zu überbrücken. Im Gegensatz zu vielen anderen Entwicklungs-Frameworks ist PhoneGap gut dokumentiert, es existiert sogar deutschsprachige Literatur dazu.

Auch wenn das – gerade im Verlagsumfeld – vielleicht noch Zukunftsmusik ist: Die Technologien in der App-Welt bewegen sich immer schneller. Auch hier bleibt nichts, wie es war…

License

Native App oder Web App? Copyright © 2012 by Harald Henzler, Andreas Wiedmann, Fabian Kern. All Rights Reserved.

Feedback/Errata

Leave a Reply

Your email address will not be published. Required fields are marked *