Menü
chevron_left
Blog » App, Web App, nativ, hybrid...?

App, Web App, nativ, hybrid...?

© Scanrail - Fotolia.com

Heute gibt es zahlreiche Möglichkeiten, eine App zu entwickeln (früher hieß das ja einfach: Software, oder Anwendung). Oftmals werden dabei die Technologien und buzz words nicht ganz trennscharf verwendet, so dass die Gefahr besteht, über unterschiedliche Dinge zu sprechen. Wir möchten dem etwas entgegenwirken und die wesentlichen "Erscheinungsformen" einer App sowie die jeweiligen Vor- und Nachteile in der Praxis aufzeigen.

Web-App

Eigentlich handelt es sich dabei um eine normale Webseite. Also etwas, das mit Hilfe eines Browsers über eine URL aufgerufen werden kann. Oft geht damit auch eine gewisse Funktionalität einher (z.B. eine Merklisten-App), gegenüber der rein informativen Darstellung von Web-Informationen. 

Web-Apps können also auch in normalen Desktop-Browsern genutzt werden. Auf mobilen Endgeräten können diese zudem ein Icon auf dem Startbildschirm erhalten, um sie schneller aufrufen zu können. Letztlich wird aber die Webseite aufgerufen, und das bedingt in den allermeisten Fällen auch eine Online-Verbindung (sehr selten gibt es bereits Ansätze, Web-Apps auch offline lauffähig zu machen).

Technologien: Web-Apps sind im Grunde genommen Webseiten, die von einem Webserver ausgeliefert werden und werden mit normalen Internet-Technologien entwickelt (HTML5, CSS3, oft auch Javascript und entsprechende Frameworks wie jQuery oder jQuery Mobile). Web-Apps, die im Desktop-Browser lauffähig sind, können für mobile Endgeräte angepasst werden ("responsive").

Vorteile: Web Apps lassen sich - vergleichsweise - schnell entwickeln und sind potentiell in jedem Browser lauffähig, also auch auf unterschiedlichen Mobil-Betriebssystemen wie iOS und Android. In der Praxis sieht das leider nicht immer so rosig aus, aber für bestimmte, definierte Szenarien haben Web Apps unserer Meinung nach Ihre Berechtigung.
Zu erwähnen ist auch, dass ein Update der App sehr schnell möglich ist, da nur der Programmcode bzw. die Inhalte auf dem Webserver geändert werden. Eine Freigabe in den App Stores entfällt.

Nachteile: Manchmal ist die Verteilung über App Stores explizit gewünscht (Image-Faktor, potentiell höhere Aufmerksamkeit und bessere Vermarktung). Bezahlfunktionen müssen aufwändig selbst implementiert werden.
Der wichtigste Faktor aus unserer Sicht: der Nutzer bemerkt ziemlich schnell, wenn er eine Web App bedient - es kommt kein "natives Nutzerfeeling" auf. Das mag banal erscheinen, aber gerade die Usability ist oft ein wesentlicher Erfolgsfaktor für gute Apps!
Weiterhin kann über Web Apps nicht auf Hardware-Funktionen (Kompass, Kamera etc.) zugegriffen werden - es gibt hier allerdings einige Ansätze, dies zu umgehen (Browser-Apis und hybride Apps).
Aus Entwicklersicht zu erwähnen ist die Programmierung mit Hilfe von Javascript. Bei Einsatz dieser Programmiersprache kann es zu Qualitätsproblemen kommen und es können unübersichtliche Anwendungen entstehen, die schwer zu warten sind und hohe Folgekosten nach sich ziehen können.

SchwerpunkteSchnelle Entwicklung von Prototypen, klar definierte Einsatzgebiete (z.B. reine B2B-App, die auf möglichst vielen Geräten lauffähig sein soll). Liegen Inhalte/Funktionalitäten ohnehin bereits als Webseite vor und würde eine native App keinen echten Mehrwert bieten - etwa durch Einsatz hardware-spezifischer Fähigkeiten eines Smartphones - mag eine Web App die richtige Entscheidung sein.

Native App 

Native Apps sind sozusagen die "eingeborenen" Anwendungen. Damit sind Apps gemeint, die ganz spezifisch für ein bestimmtes Betriebssystem entwickelt wurden und die Funktionen und Fähigkeiten optimal ausnutzen können. Auf Apple-Geräten sind das etwa iOS-Apps, die mit Hilfe der Programmiersprache Objective-C entwickelt werden, auf Google-Smartphone und Tablets Android-Anwendungen, die in Java programmiert werden.
Nutzer kennen und erwarten die Usability von nativen Apps und sind enttäuscht, wenn sich eine Anwendung anders verhält. Dies ist ein wesentlicher Erfolgsfaktor für gute Apps!

Technologien: Objective-C (Apple, iOS), Java (Google, Android) und C# (Microsoft, Windows Phone)

Vorteile: Schnelle und effiziente Apps, die auf alle Hardware-Funktionen problemlos zugreifen können, mit einem Höchstmaß an Nutzbarkeit. Verteilung über die App Stores, etablierte Zahlungsmöglichkeiten. 

Nachteile: Für jede Plattform ist eine separate Entwicklung notwendig (zu einer Ausnahme s.u. Xamarin). Entsprechend hoher Pflege- und Wartungsaufwand, sobald für mehr als eine Mobil-Plattform entwickelt werden soll. Bei einer Aktualisierung der Kernfunktionen einer nativen App kann es zu Verzögerungen durch Freigabeprozesse in den App Stores kommen.

Schwerpunkte: B2C-Apps, Spiele. Apps, die eine hohe Usability sicherstellen sollen. Hardware- und performance-intensive Apps. Apps, die auch offline funktionieren sollen.

Hybride App

Bei diesem Ansatz wird versucht, eine Web App mit einer nativen App zu kombinieren. Dabei wird im Grunde eine Webseite innerhalb einer App dargestellt. Sämtliche Inhalte und die Nutzerführung stammen jedoch aus der zugrunde liegenden Web App. Diese kann sowohl von einem Webserver (online) geladen werden, oder auch offline in der hybriden App selbst vorliegen.

Technologien: Wie bei Web Apps zunächst HTML5, CSS3 und Javascript-Frameworks. Hinzu kommt eine "native Komponente", die entweder selbst entwickelt, oder in Form von bestehenden Werkzeugen (z.B. Phonegap/Cordova) eingesetzt werden. Über diese native Komponente ist zudem auch ein Zugriff auf die Mobil-Hardware möglich. Die Web App wird sozusagen in eine "Schachtel" gepackt, die dann über die App Stores verteilt werden kann.

Vorteile: Potentiell plattformübergreifende Entwicklung möglich (in der Praxis teilweise mit deutlichen Einschränkungen). Verteilung und Bezahlung über App Stores. Teilweise Zugriff auf Hardware-Funktionen wie Kamera und GPS.

Nachteile: Fehleranfällige und aufwändige Entwicklung mit Hilfe von Javascript. Beim Versuch, möglichst viele Geräte abzudecken, führt ein hoher Abstraktionsgrad oft zu einem "kleinsten gemeinsamen Nenner" - Nutzer bemerken die eingeschränkte Usability negativ. Aktualisierungen müssen ebenfalls über die App Stores erfolgen. Performance-Probleme und eingeschränkte Stabilität = Absturzgefahr. Größere Apps werden schnell "unwartbar" und verursachen hohe Folgekosten.

Schwerpunkte: Wir halten hybride Ansätze für das "schlechteste aus zwei Welten" und raten von hybriden Apps eher ab. Grundsätzlich vorstellbar wären Szenarien wie reine B2B-Apps oder marketing-lastige Apps mit geringem Budget.    

Responsive App 

Damit ist gemeint, dass sich eine App an eine Vielzahl unterschiedlicher Bildschirmauflösungen anpassen kann, so werden etwa einzelne Seitenelemente zusammen geschoben oder anders angeordnet. Ein Smartphone hat eine andere Auflösung als ein Tablet und wiederum ein Desktop-PC. Auch gehen Nutzer mit verschiedenen Geräteklassen ganz anders um und haben ganz unterschiedliche Informationsbedürfnisse auf einem kleinen Telefon gegenüber einem großen 32"-Monitor.

Es wird jedoch nur eine einzige App entwickelt, die durch entsprechende Programmierung (CSS - media queries) "erkennt", auf welchem Gerät sie der Anwender benutzt und sich entsprechend anpasst. Damit das funktioniert, sollte dies bei der Entwicklung von vornherein mit berücksichtigt werden und ist bei Anwendung aktueller Standards (HTML5, CSS3) und bestimmter CSS-Frameworks (z.B. Twitter Bootstrap oder Zurb Foundation) relativ einfach umsetzbar.

Im Idealfall wird jedoch nicht nur die unterschiedliche Bildschirmauflösung berücksichtigt, sondern es wird auch den Informationsbedürfnissen in unterschiedlichen Nutzungskontexten Rechnung getragen: Informationen werden anders angeordnet oder entfallen auf kleinen Geräten sogar ganz.

Mobile first

Dieser Ansatz trägt diesen unterschiedlichen Nutzungskontexten Rechnung: Etwas hinzuzufügen ist einfacher, als etwas wegzunehmen.
So wird bei der Konzeption und Entwicklung einer App zunächst vom kleinstmöglichen Gerät ausgegangen, oft also einem Smartphone. Weitere Geräteklassen (Tablets, Desktop) kommen erst später hinzu. Für jedes Gerät wird überlegt, wie der typische Nutzungskontext aussieht und welche Informations- und Nutzungsbedürfnisse die Anwender haben. Dieser Ansatz erfordert ein Umdenken bei Design und Konzeption einer App!

Offline Apps

Viele Apps benötigen heute eine sporadische oder permanente Online-Verbindung, etwa über WLAN oder einen Mobilfunkanbieter. Manchmal ist dies jedoch nicht gewünscht, entweder aus Kostengründen oder in spezifischen Nutzungskontexten (z.B. bei einer Outdoor-Routingapp oder im Flugzeug). Werden externe Daten benötigt, die nicht von vornherein in der App enthalten sind, können diese bei Verfügbarkeit einer Datenverbindung geladen oder auch aktualisiert werden. Anschließend werden diese etwa in einer Datenbank lokal auf dem Gerät gespeichert.
Grundsätzlich umsetzbar sind offline Apps sowohl als Web App, hybride App oder native App

Cross-platform Entwicklung

Eine plattform-übergreifende Entwicklung ermöglicht es, aus einer einzigen Code-Basis heraus für unterschiedliche (mobile) Betriebssysteme zu entwickeln. Es wird also nur einmal programmiert, die App ist dann sowohl auf iOS, Android und Windows Phone lauffähig. Die bereits erwähnten hybriden Ansätze versprechen genau dieses, oftmals jedoch zu Lasten einer eingeschränkten Nutzbarkeit und einem hohen Abstraktionsgrad.

Ein anderer Ansatz ist ein sogenannter cross compiler - hier wird die App in einer Programmiersprache entwickelt, die anschließend in die nativen Sprachen des jeweiligen Systems übersetzt wird. Xamarin verwendet etwa die Programmiersprache C#, die dann in Java bzw. Objective-C übersetzt wird. Aus Sicht des Betriebssystems sieht eine derartige App nicht anders als eine echt-native aus.

Xamarin.iOS und Xamarin.Android

Xamarin löst das Versprechen einer plattform-übergreifenden nativen App Entwicklung tatsächlich ein: Mit Hilfe von C# können Apps entwickelt werden, die sowohl auf iOS (Apple), Android (Google) und Windows Phone (Microsoft) lauffähig sind. Ist zudem bereits C#-Code vorhanden (etwa aus bestehenden .NET-Projekten oder anderen Klassenbibliotheken), kann dieser oft problemlos weiterverwendet werden. Ein Großteil des Programmcodes ist somit wiederverwendbar, nur die eigentliche Benutzeroberfläche muss - und sollte - für jedes Mobil-Betriebssystem getrennt entwickelt werden. Je nach Projekt können ca. 50-70% des Codes weiter genutzt werden.

So entstehen Apps, die nativen-Apps in nichts nachstehen. Durch die sehr effiziente Programmiersprache C# sind zudem insgesamt kürzere Entwicklungszeiten möglich und die Programme sind gut strukturiert, testbar und wartbar.

Mit Xamarin entstandene Apps sind um 2.5 MB geringfügig größer als echt-native Apps, und diese Plattform ist derzeit in Europa noch nicht so verbreitet wie in den USA. Nichts desto trotz dürfte es auch in Deutschland erheblich mehr C#-Programmierer geben, als Experten, die sich sowohl mit iOS als auch Android (und ggf. noch Windows Phone) auskennen. 

Fazit

Es gibt für jede Anforderung eine, und manchmal mehrere, optimale Lösungen. Welche das im Einzelfall ist, lässt sich nach einer ersten Analyse der Anforderungen genauer erörtern. Die unbedarfte Entscheidung für eine der erwähnten App-Technologien kann unserer Erfahrung nach schnell zu hohen (Folge-)Kosten führen. Andererseits spricht nichts dagegen, einen Prototypen möglichst schnell entwickeln zu wollen und aus Nutzerfeedback zu lernen. Anschließend wird die App mit den neu gewonnenen Erkenntnissen auf einer passenderen Basis neu implementiert.

Am Rande: Facebook hatte sich zunächst bei der Entwicklung ihres mobilen Clients für eine hybride Plattform entschieden - und wenig später als echt-native App neu implementiert. Mark Zuckerberg nennt diese Entscheidung heute seinen "biggest mistake".

(Autor: Nils Ehnert, 3.4.2014)