Vor gut 12 Jahren gab es erste Versuche das Web für Firmen nutzbar zu machen. Damals hat DOCOMO mit iMode einen ersten Versuch gestartet per Browser Informationen darzustellen, welches aber in Europa nicht angenommen wurde und in Amerika gar nicht erst erschien.
Die Selbstdarstellung im mobilen Netz war langsam und unansehnlich. Für Firmen und Geschäfte hat sich an dieser schlechten Lösung nur langsam etwas verändert. Dazu kam dass die meisten Endkunden weder einen Datentarif hatten noch gewillt waren auf den Seitenaufbau kommerzieller Seiten zu warten.
Bis vor 4.5 Jahren ist nicht viel Nennenswertes passiert. Die Geschwindigkeit wurde langsam besser, vor allem aber über neue Netze und verbilligte Tarife, kamen mehr Nutzer mobil online.
Erst mit HTML5 und dem iPhone – später Android – wurde ein Fenster aufgestoßen mit dem diese Technologie spannend wurde. Zeitgleich entstand aus EXT.JS auch Sencha Touch und als Hobbyprojekt kam jQuery Mobile dazu. Erstmals konnte man für Webseiten Desktop Icons erstellen und so ein natives Gefühl simulieren, aber sehr stark eingeschränkt.
Auf dem iPhone / iPad wurde die Webview relativ gut unterstützt, so dass es für diese Plattform schon ein einigermaßen gutes Usererlebnis im Web gab. Seitdem strömen Firmen und Shops unaufhaltsam auf den Markt und wollen sich repräsentiert sehen.
Heute (Mitte 2013) und 4.5 Jahre später gibt es regelmäßig Diskussionen ob „Native Apps“, „Hybride Apps“ oder „WebApps“ die Lösung für einen mobilen Auftritt sind.
Der Wunsch nach mobilen Apps hält an und für Firmen und Geschäfte ist es selbstverständlich geworden sich über eine solche App mitzuteilen. Während Firmen sich Mobile Enterprise App Strategien überlegen, muss eine grundlegende Entscheidung getroffen werden. Reicht es aus über das Web auf die mobilen Geräte zu kommen oder will man über den Store und bei letzterem welche Plattformen will man unterstützen.
Anfangs wollten Firmen über den Apple Store aufgefunden werden, aber mit den neuesten Zahlen, sehen die meisten, dass Android ein absolutes Muss wird und Windows Phone auch im Kommen ist.
Genau daraus resultieren die Gespräche über „Native Apps“ vs. „Hybride Apps“.
Ein kleiner Überblick
„Native Apps“ werden in der jeweiligen Sprache der Plattform geschrieben. Meist also objective C oder Java.
Pro: Kamera, GPS und andere Hardware kann direkt angesprochen werden. Werden neue Schnittstellen benötigt, so sind die Programmierer nah am Betriebssystem und können diese einbinden (Beispiel: Pairing von Bluetooth).
Contra: Pro Plattform braucht man meist einen Programmierer, da Programmierer, die beide Plattformen sehr gut unterstützten können sehr rar sind. Hat man auf einer Plattform ein Design umgesetzt, so muss dies auf einer zweiten Plattform noch einmal umgesetzt werden. Dadurch werden zeitgleich aber auch wieder doppelt so viele Programmierer gebunden.
„Hybride Apps“ basieren auf einem HTML5/JavaScript/CSS Konstrukt und werden mit einem Wrapper in native Apps umgewandelt.
Pro: Wenn das Design einmal mittels SASS/CSS umgesetzt wurde, muss dies nur plattformspezifisch angepasst werden. Standard Plattformdesigns bringen die meisten Frameworks schon mit.
Hat man einmal eine HTML5 App geschrieben, so können Wrapper diese zeitgleich für iOS, Android, Windows Phone, Blackberry und weitere Formate erstellen.
Contra: Mittelmäßige Ergebnisse können auch Einsteiger erzielen, aber qualitativ hochwertige Ergebnisse, benötigen Erfahrung. Nachteile – meist auf Android – sind Listen mit mehr als 50 Einträgen, die im Vergleich zur nativen Lösung nicht ganz so flüssig laufen (auf Android) oder auch Verzögerungen im Millisekunden-Bereich nach einem Button-Tap. Und wenn man Hardware direkt ansprechen möchte, die dem Wrapper als Plug-In nicht vorliegt, braucht man wieder native Programmierung.
„WebApps“ bietet die Möglichkeit mit kurzen Entwicklungszeiten auf vielen Plattformen vertreten zu sein. Frei nach dem Motto: Einmal geschrieben, überall präsent. Updates können kurzfristig alle User erreichen und man kontrolliert den Inhalt selbst. Es gibt keine Mitverdiener bei kommerzieller Anwendung. Das Speichern von Userdaten offline ist möglich und wenn das Lesezeichen auf dem Desktop abgelegt wird, erscheint dies fast als App.
Pro: Webseiten können relativ einfach in eine solche App umgewandelt werden und sodass die Webseite offline navigierbar ist.
Contra: Es ist nur die Kamera ansteuerbar, andere Hardware nicht. Daten haben keinerlei Sicherheit (Dateneingaben können manipuliert werden, Datentransfer ist offen und es ist möglich über Codeinjection die Seite zu übernehmen, Verschlüsslung nur schwer realisierbar und nie ultimativ sicher).
Fazit
Jede dieser Plattformen hat Vor- und Nachteile, aber die endgültige Entscheidung ist von so vielen Faktoren abhängig, dass man diese nur pro Projekt klären kann.
Reine WebApps als Enterprise Solution, lasse ich hier außer Acht, da diese, sobald es sich um sicherheitsrelevante Daten handelt, nicht geeignet sind.
Zwei wichtige Faktoren kann ich am besten an Charts festmachen:
Ergänzung: Baukasten-Apps
Einige Firmen bieten „native Apps“ basierend auf einem Baukastensystem an. Diese habe ich hier außen vor gelassen, da diese Apps zwar die Vorteile der Geschwindigkeit in der Darstellung mitbringen, aber nur unzureichende Individualisierbarkeit bieten, Daten genauso angeliefert werden müssen, wie das System es erfordert und die Hardware meist weniger unterstützen als „hybride Apps“. Damit sollten sich diese Apps also im absoluten Billigpreis-Segment ansiedeln.