Native App oder Web App? Teil 2: Welche App Technologie ist für welchen Zweck besser geeignet?

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 der Anforderungen an eine Anwendung gibt, für die der Web-Ansatz oder der Native-Ansatz besser oder schlechter geeignet ist.

Update 2017: Für Konsumenten wie Anbieter sind in den Jahren seit der Veröffentlichung unseres Artikels 2012 die Möglichkeiten des Publizierens in den Ökosystemen von Apple, Google und Co. zur alltäglichen Selbstverständlichkeit geworden. Dennoch ist in nahezu jedem größeren Projekt zum Mobile Publishing die wesentliche technische Frage zum Projektstart dieselbe geblieben: Welches ist die geeignete Produktform? Soll es eine native App oder eine Web-App werden? Oder ist ein hybrider Ansatz doch sinnvoller? Nach der Vielzahl an technischen Neuerungen in den letzten Jahren ist es Zeit für ein Update: Lesen Sie deshalb auch unsere aktuelle Artikelserie zur erfolgreichen Implementierung von App-Projekten.

Anwendungsmerkmale, die sich besonders für Native Apps eignen

  • “Fancy UIs (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-Sternenkarte mit 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

  • “Straight forward-UIs (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.

Siehe hierzu auch Teil 1, Native App oder Web App?  Teil 1: Definitionen und Entscheidungskriterien und Teil 3, der sich sich mit möglichen Kombinationen der beiden Modelle und den Handlungsempfehlungen dafür beschäftigt.

Veröffentlicht von

www.dpc-consulting.de

XML- und Digital-Publishing-Professional mit Leib & Seele, seit Berufseinstieg in verschiedensten Projekten rund um Content-Management und Datenbank-basiertes Publizieren unterwegs. Seit 2012 selbständig als Berater und Trainer für digitales Publizieren.