Native App oder Web App? Teil 1: Definitionen und Entscheidungskriterien

Die Grundfrage für Verlage und Buchhandlung ist doch immer, ob sich denn Apps rechnen können? Ein Produkt für 0,79 €  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. Diese soll in einer Serie von drei Beiträgen erfolgen: Teil 1 zu “Definition und Entscheidungskriterien”, Teil 2 zu “Welche Technologie für welchen Zweck?” und Teil 3 zu “Die Kombination der Modelle”.

Die SPIEGEL-App hatten wir als jüngeres Beispiel für eine (Mobile) Web App vorgestellt, weil hier der Versuch gemacht wird, unabhängig von Apple und anderen Ökosystemen zu handeln. Der Verlag will wieder autark werden. Die dabei zum Einsatz kommenden Web-Technologien rund um die „Generation HTML5“ werden hier im Unterschied zu den “nativen” Apps erläutert.

Definitionen für Kriterien von Native Apps vs. Web Apps

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 seinerzeit 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.

Bei der in diesem ersten Teil geführten Diskussion über die Merkmale von Nativen Apps vs. Web Apps, könnte der Eindruck entstehen, als wären Web App und Native App zwei 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. Dieser scheinbare Widerspruch wird durch den dort aufgezeigten Lösungsweg aufgelöst…

Mehr dazu im Teil 2 und einer Darlegung, welche App für welchen Zweck eher geeignet ist und Teil 3 und der möglichen Kombination.