Nativ, Hybrid, Web App? Oder darf es eine mobile Website sein?

Nativ, Hybrid, Web App? Oder darf es eine mobile Website sein?

26.03.2012

Ich hab mal den Fehler gemacht, auf dem Podium einer Veranstaltung zum Thema „Mobile Web vs. App“ den Spruch „Jedem Depp seine App!“ zu bringen. Natürlich hab ich dort diese Aussage entsprechend relativiert verpackt. Nicht so die Journalisten, die über die Veranstaltung berichteten. Mehrere Artikel trugen den Spruch als Headline und wiesen ihn mir im ersten Absatz zu. Ganz zu schweigen von den vielen Tweets, die den praktisch kurzen Satz dankbar verbreiteten. Meine Kollegen, die sich um unser App-Business kümmern, waren alles andere als begeistert.

Mit „Jedem Depp seine App“ wollte ich aber nur ausdrücken, dass eine native Smartphone App nicht immer (aber oft) die geeignetste Form der mobilen Präsenz ist. Dass native Apps häufig als die einzige Lösungsvariante gesehen werden, zeigen uns Kundenanfragen, die – ohne andere Möglichkeiten in Erwägung zu ziehen – „eine iPhone App und vielleicht auch eine Android App“ bestellen. Wenn das Sinn macht, bauen wir die gerne. Wenn nicht, erklären wir dem Kunden die anderen Möglichkeiten und deren Vor- und Nachteile. Das beginnt zunächst mal mit der Erklärung der Begriffe:

Native App: ist speziell für das jeweilige Betriebssystem (Apple, Android, Windows Phone, Symbian, Blackberry etc.) programmiert; hat die beste User Experience; ist aber recht teuer zu erstellen und zu betreiben – vor allem, wenn man mehrere Betriebssysteme bedient, was notwendig ist, wenn man ausreichend Reichweite erzielen möchte; funktioniert auch offline (außer man braucht neue Daten während der Session); Vertrieb über App Store (iPhone), Google Play (Android) usw.

Hybrid App: günstigere Entwicklungs- und Betriebskosten mit Hilfe von Frameworks – das heißt es muss nicht für jedes Betriebssystem gesondert entwickelt werden; “Feels Like Native” – aber dann doch nicht so ganz. Die User Experience ist vor allem bei komplexer Interaktion nicht so gut wie bei Native Apps; Zugriff auf Hardware Funktionen, wie z.B. Kamera, Kompass etc., nur (leicht) eingeschränkt möglich¹, Vertrieb über App Store (iPhone), Google Play (Android) usw.

Web App: läuft am Browser, nutzt Webtechnologie (meist moderne Webtechnologie wie HTML5 und CSS3); wird wie eine normale Website über den Browser angesteuert oder auch mit Lesezeichen-Icon am Springboard wie eine Native App (in iOS); im Idealfall von einer Native App oder Hybrid App auf den ersten Blick kaum zu unterscheiden (z.B. wird das Browserfenster ausgeblendet); geringere Entwicklungskosten und hohe Reichweite, weil Betriebssystem-übergreifend nutzbar; schwächere User Experience als Native App; Zugriff auf Hardware Funktionen nur eingeschränkt möglich; Vertrieb über App Stores nicht möglich.

Mobile Website: technisch kein grundlegender Unterschied zu Web Apps (meistens technisch aber weniger aufwendig); ist aber hinsichtlich Userführung und Funktionalität eher wie eine Website und weniger wie eine typische App aufgebaut (Hier wird die Definition etwas schwammig, da es auch native Apps gibt, die wie eine Website aufgebaut sind); wird meist als mobile Variante der „großen“ Desktop Website verstanden.

Soweit zu den Begriffen. Jetzt zur Frage: Welche dieser Varianten ist für welchen Zweck geeignet? Folgender Entscheidungsweg hilft bei der Beantwortung:

  • Ist von einer häufigen Nutzung seitens des Users auszugehen? Wenn nicht, dann reicht eine mobile Website. Es ist nämlich nicht davon auszugehen, dass sich jemand, der z.B. den Jahresbericht einer Bank recherchiert, die entsprechende Bank-App runterlädt. Er sucht vielmehr die (hoffentlich mobil optimierte) Website der Bank im Web. Wenn aber von häufiger Nutzung ausgegangen werden kann, dann bietet sich eine App an, z.B.: eine App für mobiles Online Banking.
  • Spricht die häufige Nutzung für eine App, stellt sich als nächstes die Frage, ob folgende K.O. Kriterien für Web Apps greifen²: Muss die App offline funktionieren? Soll mit der App Geld verdient werden (Geht zwar mit Web Apps auch aber deutlich schwieriger)? Soll die App über den App Store o.ä. vertrieben werden? Sind Gerätefunktionen (Kamera, Accelerometer, Kontakte etc.) erforderlich, auf die mit einer Web App nicht zugegriffen werden kann³?
  • Greift eines der Kriterien bleiben noch Hybrid App und Native App. Wenn optimale Performance und Userexperience und/oder der Zugriff auf ganz bestimmte Gerätefunktionen4 erforderlich sind, dann – und nur dann – sollte man nativ entwickeln.
  1. Abhängig vom Betriebssystem
  2. Frei nach Daniel Haller, 2011 – siehe http://www.slideshare.net/dhalla/mobile-strategy-apps-webapps-hybridapps
  3. Genaue Prüfung erforderlich. Abhängig vom Betriebssystem können gewisse Gerätefunktionen mittlerweile auch mit Web Apps angesteuert werden können.
  4. Genaue Prüfung erforderlich. Abhängig vom Betriebssystem
ZURÜCK
TEILEN:
comments powered by Disqus
Alexander Reiberger
Alexander Reiberger

gründete 2005 die Agentur FONDA Interaktive Medien und Kommunikation GmbH. Davor war er drei Jahre Geschäftsführer der Digital-Agentur DMC 01 und davor zwei Jahre Internet-Koordinator der Mobilkom Austria AG.

MEHR VON DIESEM AUTOR

gründete 2005 die Agentur FONDA Interaktive Medien und Kommunikation GmbH. Davor war er drei Jahre Geschäftsführer der Digital-Agentur DMC 01 und davor zwei Jahre Internet-Koordinator der Mobilkom Austria AG.

MEHR VON DIESEM AUTOR