Ein Plädoyer gegen hybride Apps

Ich bin ja ein großer Verfechter von echt-nativen Apps und insbesondere der Xamarin-Entwicklungsumgebung. Häufig erhalte ich Anfragen, eine hybride App (etwa mit PhoneGap) umzusetzen. Nein, mache ich nicht! Warum ich hier contra gebe? Die Nachteile hybrider Apps möchte ich ein wenig näher darstellen und meine Haltung begründen.

Begrifflichkeiten

Bart Simpson schreibt 100mal an die Tafel: „Eine PhoneGap-App ist KEINE native App!“.

Hybride Apps sind Web-Apps (HTML!), die in einen nativen App-Container verpackt werden – mehr nicht. Damit ist es also möglich, Web-Inhalte in die App-Stores zu bringen, aber echt-native Apps entstehen so nicht. Hier herrscht offensichtlich ein großes Unverständnis der Technologien.

Entwicklungs-Framework

  • Javascript ist eine Interpreter-Sprache. Programmierfehler sind so bei der Entwicklung deutlich schwerer zu finden und treten schlimmstenfalls erst zur Laufzeit auf. Das führt zu einem erhöhten Aufwand für Programmtests und zu mehr nicht entdeckten Bugs – schlimmstenfalls zu mehr App-Crashes. Kompilierte Sprachen wie C# liefern bereits vor der Ausführung detaillierte Fehlerhinweise. Ja, es gibt mittlerweile halbwegs brauchbare Entwicklungsumgebungen auch für JavaScript & Co. Aber: warum nicht gleich das richtige Werkzeug einsetzen?
  • Javascript ist keine besonders gute oder moderne Programmiersprache. Viele Funktionen müssen über zusätzliche Bibliotheken oder Cross-Compiler (Coffeescript & andere) erst nachgerüstet werden. Das erhöht wiederum die Komplexität der „Tool-Chain“ und entsprechend die Fehleranfälligkeit. Nur weil es geht, muss es nicht richtig sein!
    Moderne Sprachen wie Swift oder C# bieten einen hohen Sprach-Komfort und sehr mächtige und präzise Befehle.
  • Javascript ist insgesamt schwer zu debuggen, es gibt wenige Tools (Profiler), um etwa Laufzeitverhalten und Speicher-Auslastung zu messen. Dann doch lieber gleich eine professionelle Entwicklungsumgebung wie XCode oder Xamarin verwenden.
  • Javascript alleine reicht nicht. Es werden eine Vielzahl zusätzlicher Frameworks und Dritt-Bibliotheken benötigt, die jede für sich Fehler beinhalten können und zudem regelmäßig aktualisiert werden müssen. Dabei besteht die Gefahr, dass Inkompatibilitäten auftreten. Natürlich besteht dieses Problem auch bei Zusatz-Bibliotheken für native Apps, aber nicht in einem so großen Ausmass. Ein gutes Plattform-Framework (iOS-SDK, Android-SDK, Xamarin/.NET) bietet von Haus aus vielfältige und fehlerfreie Bibliotheken.

Plattformübergreifende Entwicklung

  • Hybride Apps werden auf Basis von HTML5, CSS3 und JavaScript entwickelt. In der Praxis zeigt sich jedoch, dass oft doch wieder plattformspezifische Anpassungen vorgenommen werden müssen, da die Browserplattformen HTMLund CSS unterschiedlich interpretieren. Der Zeitvorteil hybrider App-Entwicklung wird meines Erachtens so schnell wieder aufgezehrt. Und natürlich ist auch dies eine neuerliche potentielle Fehlerquelle – „CSS-Frickelei“ macht nicht wirklich Spass.
  • PhoneGap bietet lediglich einen Rahmen – das Innenleben muss mit weiteren JS-Frameworks (wie z.B. Meteor oder Ionic) gefüllt werden. Diese funktionieren mehr oder weniger gut – in jedem Fall benötigen sie Einarbeitungszeit. Für ein spezifisches JS-Framework Entwickler zu finden, kann unter Umständen problematischer sein, als einen erfahrenen iOS- oder Xamarin-Entwickler zu suchen. Auch sind diese Frameworks oft OpenSource-Projekt mit teilweise ungewisser Zukunft oder unvorhersehbaren Änderungen, die schnell zu kompletten Code-Überarbeitungen führen können.

GUI und Usability

  • Die Benutzeroberfläche in hybriden Apps basiert wie geschrieben auf HTML5/CSS3. Alle Oberflächen-Elemente (wie Buttons, Listen, Navigationselemente etc.) müssen also „nachgebaut“ werden. Hierzu sind weitere UI-Frameworks (jQuery/Mobile, SenchaTouch u.a.) notwendig: weitere Einarbeitungszeit, mehr Komplexität, weitere Fehlerquellen.
    Das Hauptargument ist aber, dass diese UI-Elemente niemals nativ sind – und das bemerken Benutzer auch ziemlich schnell! Etwas „stimmt“ nicht, die App „fühlt“ sich nicht richtig an. Benutzer kaufen ein Smartphone aber genau wegen des einzigartigen Benutzererlebnisses (User Experience) und sind – im Falle von Apple – auch bereit, dafür sehr viel Geld zu bezahlen. Dann sollen sich die Apps aber auch genauso anfühlen, wie Nutzer dies gewohnt sind!
    Eine native Benutzererfahrung ist ein klarer Wettbewerbsvorteil! Die Benutzerbewertungen vieler PhoneGap-Apps in den Stores sprechen hier für sich, und eine schnelle Analyse der PhoneGap-Referenzen hat ergeben, dass mittlerweile einige der angepriesenen Apps auf eine echt-native Implementierung gewechselt haben – warum wohl?
  • PhoneGap versucht, zumindest einige UI-Elemente dann doch wieder nativ zu implementieren. Klingt für mich nach „von hinten durch die Faust ins Auge“ – warum nicht gleich richtig und echt-nativ? Liebe JS-„Programmierer“: die Programmierung in Swift oder C# tut wirklich nicht weh und erweitert euren Horizont ziemlich…

Gerätespezifische Funktionen

  • Hybride Apps können dank PhoneGap & Co. auf eine Reihe von hardwarenahen Gerätefunktionen zugreifen (GPS, Kompass, Beschleunigungssensor etc.). Es gibt jedoch Grenzen, die hier – wenn überhaupt – nur mit großem zusätzlichen Aufwand überschritten werden können. Das wird insbesondere noch bei iBeacons, der Apple Watch, Heimautomatisierung und anderen neuen Technologien interessant werden. Ja, es wird Module für PhoneGap geben, die aber dann doch wieder Begrenzungen haben werden. Besser: die App gleich echt-nativ implementieren.

Kosten

  • Die reine Codierung und Entwicklung einer App macht in größeren Projekten nur einen Teil der Kosten aus. Konzeption, UX-Design, Testen und nicht zuletzt die notwendigen Server-Infrastrukturen (etwa bei verteilten Messaging-Anwendungen oder Backend-basierten Apps) machen vermutlich den größeren Teil der Kosten aus. Insofern ist der – behauptete – Kostenvorteil von PhoneGap und ähnlichen Frameworks ohnehin relativ zu sehen.
  • Es scheint sich in den Köpfen festgesetzt zu haben, dass App-Entwicklung teuer und aufwändig ist. Das mag zutreffend sein, wenn eine App tatsächlich 3fach (iOS, Android und Windows Phone) programmiert werden muss. Abhilfe bieten hier jedoch Umgebungen wie Xamarin, die echt-native Apps erzeugen und einen sehr hohen Grad an Code-Wiederverwendbarkeit bieten (bis zu 95%). Und natürlich darf man sich nicht von überteuerten Agenturen über den „Tisch ziehen“ lassen.

Gesamtbetrachtung

Es gibt im Netz eine Menge Seiten, die die Vor- und Nachteile von hybriden Apps aufzeigen und mit nativen Apps vergleichen. Dabei werden oft jedoch nur einzelne Faktoren miteinander verglichen, dies zudem meist sehr subjektiv. Das greift aber deutlich zu kurz, da es sich bei halbwegs größeren App-Projekten um Software-Entwicklungsprojekte mit all ihrer Komplexität handelt. Dazu gehören aber sehr viel mehr Faktoren wie:

  • Fehlerfreiheit im gesamten Entwicklungsprozess
  • Gute und automatisierte Testbarkeit von Code und Nutzeroberfläche
  • Bestmögliche Benutzererfahrung (Usability)
  • Möglichst einfache Wartbarkeit und Weiterentwicklung
  • Einbindung in vorhandene IT-Infrastrukturen
  • Investitionssicherheit und langfristige Planbarkeit.

Für die „schnelle Endkunden-App“ ist das möglicherweise nicht so wichtig, aber besonders bei Enterprise-Apps im Business-Umfeld spielen diese Faktoren meiner Erfahrung nach eine wichtige Rolle.

Insgesamt scheint für mich das Versprechen, mit PhoneGap & Co. schnell, einfach und plattformübergreifend entwickeln zu können nur für sehr kleine und wenige komplexe Apps zu gelten. Bei steigenden Anforderungen wird man in der Praxis recht schnell an die Grenzen gelangen. Häufig führt dies dann dazu, die App komplett neu zu implementieren – manchmal mitten im laufenden Projekt! Warum also nicht von vornherein die besseren Werkzeuge einsetzen?

Und auch für schnelle Prototypen bieten zeitgemäße Entwicklungsumgebungen bereits erhebliche Vorteile gegenüber hybriden Apps. Mit Hilfe von Xamarin lassen sich Prototypen (mindestens) genauso schnell entwickeln, wie auf einer hybriden Basis – bei besserer Usability und natürlich ebenfalls plattformübergreifend aus einer einzigen Code-Basis heraus für iPhone und Android.

Grundsätzlich lässt sich mit JS-basierten hybriden App-Frameworks tatsächlich eine Menge erreichen, irgendwie „kriegt man es dann doch hin“ – aber: wie groß ist der Aufwand dafür im Gegensatz zu anderen und besseren Werkzeugen?

Man kann auch mit einer Banane einen Nagel in die Wand schlagen, wenn die Banane vorher mit einer Metallschicht überzogen wurde und zusätzliche Verstärkung erhält.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.