Zum Inhalt springen

Podcast: Native Apps versus Web-Technologien

Letzte Änderung: Mai 2020

Seit über 25 Jahren sind wir ein stabiler Partner für Kunden aus unterschiedlichen Branchen. Unser gesammeltes Wissen aus alle diesen Jahren und Projekten geben wir gerne weiter – unter anderem in Podcasts wie diesem!

Weitere Podcasts finden Sie auf unserer Übersichtsseite!


Mit Web-Technologien können zunehmend mehr funktionsfähige Apps gebaut werden. Warum also noch eine Apps speziell für iOS oder Android umsetzen? Dieser Frage widmen wir uns in diesem Podcast!

Wir schrieben das Jahr 2010 als einer unserer wiss- und lernbegierigen Entwickler das erste Smartphone für die mobile Software-Entwicklung besorgte. In den Jahren danach wurde dieser Entwickler zu einem unserer Product Owner mit umfassendem Wissen rund um Apps – und wir haben unzählige, teils hochkomplexe Software-Projekte für Smartphones und Tablets umgesetzt.

Am Bild sehen Sie unseren ehemaligen Kollegen Johannes Wirgler, damals noch Entwickler, im Jahr 2010 mit dem ersten Smartphone der CSS für die mobile Entwicklung.


Natürlich hat sich in diesem Bereich sehr viel getan – was vor kurzem noch Standard war, ist heute schon wieder überholt. Seit einiger Zeit beobachten und nutzen wir Web-Technologien, auf deren Basis man in der Zwischenzeit voll funktionsfähige Apps bauen kann. Oft stellt sich die Frage, ob die Zeit der sogenannten nativen Apps abgelaufen ist (also Apps, die zum Beispiel speziell für iOS oder Android entwickelt werden). Dieser Frage widmen wir uns in unserem aktuellen Podcast. Hören Sie sich das an!

Am Bild: Eines unserer Home-Office-Tools, Discord, verbindet uns auch für den Podcast: Bernhard ReubergerHarald DeitzerIsabel Birnstingl und Johannes Wirgler im Gespräch.


Transkript des Podcasts (gekürzte Fassung)


Isabel:
Hallo, herzlich willkommen zu diesem Podcast, der Teil der Reihe "Einblicke" des Software-Team CSS in Wien ist.

Kommen wir zum Thema dieses Podcast. Unter unseren Referenzen finden sich auch einige App-Projekte und wir beschäftigen uns laufend mit den neuen Technologien und Entwicklungen in diesem Bereich.

Seit einiger Zeit sind Webtechnologien bei der Umsetzung von mobilen Apps auf dem Vormarsch und es stellt sich immer mehr die Frage, ob die Umsetzung nativer Apps – also das sind, sehr vereinfacht gesagt, Apps, die für ein bestimmtes Betriebssystem wie z.B. iOS oder Android gebaut werden – ob die Umsetzung solcher nativer Apps überhaupt noch Sinn macht.

Auf diese Frage möchte ich gern gemeinsam mit drei meiner Kollegen eingehen, die ausgewiesene Experten auf diesem Gebiet sind. Harald Deitzer ist einer unserer Product Owner, das heißt er ist eine Schnittstelle zwischen dem Kunden und den Entwicklungsteams bei uns in der CSS. Ebenfalls mit dabei ist Bernhard Reuberger, er ist einer unsere Senior-Softwareentwickler und hat eine ganze Menge Erfahrung in der Umsetzung von mobilen Apps. Unsere Runde wird vervollständigt durch Johannes Wirgler, der nicht nur als Produkt Owner schon einige App-Projekte betreut hat, sondern, wenn ich mich richtig erinnere, auch das Thema App-Entwicklung überhaupt vor einigen Jahren in CSS gebracht hat, stimmt das, Johannes?


Johannes:
Hallo Isa, ja, ich war der erste.


Isabel:
Ich glaube, da gibt es sogar noch ein Bild von dir, wo du das erste Smartphone für die Softwareentwicklung, also mobile Softwareentwicklung in die Kamera hältst. Ich glaube, das stelle ich dann auf der Website dazu zu diesem Podcast.


Johannes:
Das wäre sicher lustig.


Isabel:
Gut, kommen wir gleich mal zum Thema. Ich habe jetzt gerade die Web-Technologien erwähnt, die immer mehr im Kommen sind. Bernhard, als einer unserer Softwareentwickler, kannst du dazu mehr erzählen?


Bernhard:
Ja, Stand heute ist es so, dass die Web-Technologien immer mehr Möglichkeiten bieten, um Applikationen auch für mobile Endgeräte gut umzusetzen. Unserer Meinung nach gibt's da drei besonders relevante Punkte: Zum einen haben wir immer mehr und mehr Zugriff auf die Geräte-Sensoren und die Eigenschaften von Geräten. Zum Beispiel die Standortabfrage, die jede Webapplikation machen kann. Und diese Liste erweitert sich momentan ständig. So hat man auch Zugriff auf den Kompass, auf die Geräte-Ausrichtung, auf die Vibrationsschnittstelle und sogar so Dinge wie den Akkustatus, Batterie-Level und nicht zuletzt auch auf Kamera und Audio.

Zum Zweiten werden auch die mobilen Endgeräte an sich immer stärker. Das ist sehr wichtig bei Web-Technologien für die Usability, weil je stärker das mobile Endgerät, desto besser, desto flüssiger fühlt sich das an.

Und zum Dritten – für uns als Entwickler auch sehr wichtig – werden auch die Entwicklungstools und Entwicklungssprachen und die Frameworks immer besser. Zum Beispiel Angular, React oder auch Vue.js. Das sind etablierte Frameworks und für uns einfach Hilfestellungen, wie wir sehr stabile Webclient-Software schreiben können, so wie wir es von der nativen Entwicklung gewohnt sind, mit Tests, mit typisierten Programmiersprachen und so weiter.


Isabel:
Okay, das ist heißt, Webtechnologien übernehmen schon viel was man früher nur mit diesen nativen Apps machen konnte. Aber es gibt ja eigentlich nicht nur Webapplikationen und native Apps, sondern es gibt unterschiedliche Formen von Apps. Möchte dazu jemand von euch was sagen?


Johannes:
Wir haben begonnen damals für die Orange ganz nativ zu Entwickeln für die ganz alten Nokia-Handys. Ich weiß nicht, ob sie noch jemand daran erinnern kann, die haben drei Zeilen Schwarz-Weiß-Display gehabt. Dann hat sich die Smartphone-Geschichte entwickelt und dann ist die Möglichkeit entstanden, dass man mit verschiedenen Frameworks auch auf dem Handy arbeiten kann mit Webtechnologien, die dann auf dem Gerät gerendert werden. Das wären dann die nicht-nativen Applikationen, die im Browser laufen. Den Ansatz, den wir gewählt haben, weil wir die besten Erfahrungen damit gemacht haben, war, dass wir eher Hybrid- oder Container-Apps gemacht haben. Container-Apps deswegen, weil hier wird nur der Rahmen nativ gebaut, und die Navigation fühlt sich dann auch so an – egal ob es jetzt iOS, Android oder damals Windows Phone war – wie er es gewohnt ist. Und der Inhalt wurde mit Web-Technologie dargestellt.

Hybrid-App haben wir damals dann auch verwendet, da haben wir dann alles, was sozusagen nativ zu verwenden ist – weil es ja damals noch keine Web-Technologie-Unterstützung gegeben hat von den Browsern her für verschiedene Geräte-Eigenschaften wie zum Beispiel Vibration, Kamera – da haben wir Hybrid-Apps gemacht.


Isabel:
Dann bleiben wir bei den nativen Apps, dem Thema des Podcasts. Bernhard hat gesagt, es gibt ganz viele Möglichkeiten mit Web-Technologien schon. Wieso setzen wir dann eben noch immer native Apps um? Oder lasst es mich anders formulieren, wenn jetzt ein Kunde zu uns kommt mit einem App-Wunsch, wie geht ihr da das mit ihm durch, um zu einer Entscheidung zu kommen native App oder nicht?


Harald:
Genau, also, dazu kann ich vielleicht was sagen als Product Owner. Ich bin sehr oft in einer Situation in einem Erstgespräch mit einem Kunden wo teilweise schon ein stark ausgeprägter Wunsch nach einer App da ist. Wir gehen eigentlich in allen Erstgespräche noch mal einen Schritt zurück, erfragen, was soll denn mit der App überhaupt erreicht werden, was ist denn die Vision, was soll inhaltlich mit der App gemacht werden. Aus diesen Punkten ergeben sich natürlich ein paar Antworten, die bei uns so etwas wie Kennzahlen sind, was spricht eher für eine App, was spricht vielleicht für eine Hybrid- oder Container-App. Oder muss es gar keine App sein, sondern ist es eine Website, die einfach nur auf einem mobilen Endgerät auch gut ausschauen soll. Und es gibt eben einige Punkte, die wir abfragen. Aber da können vielleicht doch die Kollegen noch etwas aus dem jeweiligen Spezialgebiet dazu sagen.


Isabel:
Vielleicht Johannes, du hast ja auch als Product Owner einige App-Projekte gemacht. Was wären denn so Dinge, die du dir überlegen würdest, gemeinsam mit dem Kunden?


Johannes:
Also, ein Punkt, der mir sofort einfällt ist, wie die Applikation benutzt werden soll oder wie sie sich anfühlt, wie man damit interagiert. Das was man heutzutage auch UX-Design nennt. Gibt's Spezialisten in dem Fachgebiet. Ja, und da geht es darum dass man sich anschaut, wie benutzt der User die Applikation, wie ist er es – beim Vergleich dann – wie ist er es gewohnt zu benutzen. Also, wenn man jetzt klassisch den Desktop hernimmt, würde er ja Maus und Tastatur hauptsächlich benutzen. Wenn er eine Mischgerät hat, wo er auch einen Touchscreen hat, kann man auch auf das Rücksicht nehmen.

Bei einem mobilen Gerät, die meistens ohne Tastatur zu finden sind, würde er ja nur Touch verwenden und natürlich ist der Bildschirmausschnitt auch viel kleiner. Dass heißt, man muss sich ganz genau überlegen, okay wo legt man jetzt die wichtigen Funktionen hin, wie verhält sich der Touch. Und wenn man da ja jetzt sehr viel nicht-nativ arbeitet, dann kennt sich der User nimmermehr aus. Weil er klickt dann auf bekannte Stellen und dort passiert nichts, er hat dann bestimmte Buttons, die er am Gerät zur Verfügung hat als Hardware-Buttons zum Beispiel oder Software-Buttons wo nichts passiert, wenn er drauf klickt und das wäre ganz schlecht. Deswegen ist Usability ein ganz großes Thema auch in mobilen Applikationen und Desktop-Applikationen und man muss sich dann schon bei der Konzeption und im Vorfeld entscheiden, was ist denn wichtig und was will man denn erreichen gemeinsam.


Isabel:
Ein Thema, das mir gerade einfällt, ist das Thema "offline". Also, jeder der unterwegs ist, wird merken, dass man manchmal mehr manchmal weniger Internetverbindung hat. Spielt das auch eine Rolle das Thema?


Bernhard:
Ja, genauso, definitiv. Da ist der Riesen-Unterschied, dass die nativen Plattformen von Anfang an das Thema Offline-Fähigkeit in den Fokus gerückt haben. Die wurden mit dem Mindset entwickelt, die Benutzer haben nicht immer Internet, die Applikation muss sich auch gut anfühlen, wenn ich gerade kein Internet habe und ich als Benutzer muss es vielleicht gar nicht mitbekommen, dass ich kurzfristig keine Internetverbindung hatte und die Applikation funktioniert trotzdem wie gewohnt. Das war von Anfang an im Mindset der nativen Plattformen drinnen. Beim Web gibt es jetzt schon sehr viele Möglichkeiten; es geht in die Richtung. Es ist noch immer der große Unterschied, dass Web von den anderen Standpunkt gestartet hat. Im Web war man immer online und am Desktop im Browser war man immer online. Man hat sehr viel Rechenleistung zur Verfügung gehabt, man hatte keinen Akku, außer auf den Laptops dann später.
Es ist einfach der Standpunkt in anderer, wo jetzt mit dem Progressive Web Apps sich sehr viel tut und man sehr wohl Offline-Fähigkeit einbauen kann. Man merkt die große Hilfestellung, die native Plattformen hier geben, angefangen von Android zum Beispiel – du kannst dem Betriebssystem sagen, bitte notifizieren mich, wenn der Benutzer oder die Benutzerin das Handy angesteckt hat, weil jetzt ist genug Akku zur Verfügung oder genug Strom zur Verfügung, dass ich meine Daten aktualisieren kann.

Des Weiteren gibt es auf den nativen Plattformen, weil das Thema schon so lange so präsent ist, auch sehr viele Frameworks oder Third Party Frameworks und generell sehr viele Ressourcen zum Thema Datenpersistierung, die dann einem die Entwicklung erleichtern.


Isabel:
Was genau ist Datenpersistierung? Da muss ich jetzt selber fragen.


Bernhard:
Das ist einfach Datenspeicherung. Damit sie offlinefähig sein können, müssen wir die Daten, die wir meistens vom Internet laden am Gerät speichern und das ist die Datenpersistierung. Damit wir sie später wieder abrufen können sobald keine Internetverbindung da ist.


Isabel:
Verstehe, alles klar. Wir haben jetzt das Thema Usability und Interaktivität und Offline-Fähigkeit. Gibt's noch etwas was eine Rolle spielt bei der Entscheidung für eine native App?


Harald:
Dann sage ich vielleicht auch noch mal was dazu. Also meiner Meinung nach und was ich auch mit vielen Kunden in einem Erstgespräch erwähne oder zumindest diskutiere, ist natürlich schon die Möglichkeit der Store-Infrastruktur, die die jeweiligen Plattformen bieten. Also den Google Play Store oder bei Apple den App Store, der einfach mal per se eine Möglichkeit bietet, nach Apps zu suchen. Eine Usability von von dem her, die die Benutzer der jeweiligen Plattform natürlich auch gewöhnt sind und sicher der Haupt-Zugangspunkt sind, wenn ich mich entscheide, eine Applikation zu suchen oder vielleicht eine zu installieren ist sicher der erste Weg in die Stores.

Auch weil es kein wirklich flächendeckendes Konzept für Web-Apps gibt, die ich so einfach durchsuche. Das geht ein bisserl Hand in Hand was Bernhard jetzt mit Offline-Fähigkeit erwähnt hat. Also, dort spürt man das auch das erste Mal – ich installiere mir die App wirklich auf mein Handy, die App ist auf meinem mobilen Device und auch als App-Entwickler beschäftige ich mich dann vor allem damit inhaltlich, wo braucht die App eine Internetverbindung versus eine mobile Website. Einfach schon nur zum Aufrufen schon mal eine Internetverbindung voraussetzt, wenn man es nicht eben speziell entwickelt, dass man die auch auf dem Gerät vorhält. Ja, das ist ein Punkt, der mir noch einfällt.


Isabel:
Ja, das ist ein guter Punkt. Ich habe gerade überlegt, ich als Besitzerin eines iPhones, wenn die App nicht im Store ist, existiert sie für mich nicht. Also das mit den Stores ist sicherlich auch sehr guter Punkt. Gut gibt's noch ein Thema?


Bernhard:
Was uns als Entwickler auch immer wieder auffällt, ist das Thema Lebensdauer oder dann Wartung, was ja Hand in Hand geht. Wir haben die Erfahrung gemacht über die Jahre hinweg, native Applikationen sind schnelllebig aber Web-Technologien sind noch viel schnelllebiger. Das heißt, man muss sehr oft neue Frameworks sich zumindest anschauen. Es tut sich sehr viel; es haben sich mittlerweile ein paar Dinge auch bei den Webtechnologien etabliert. Zum Beispiel weil ich vorher es erwähnt habe, Angular ist ein gutes Beispiel, was sich schon bei Web-Technologien etabliert hat und sich jetzt schon mehrere Jahre lang hält, trotzdem passiert es vor allem bei Web auch oft, dass sich auch für uns das Toolset ändert; das heißt, die Dinge, die Programme, die wir wiederum verwenden, um die Programme zu schreiben, die sind bei nativen Applikationen sehr konsistent. Da hat's bei Android vor Jahren einen Wechsel von Eclipse zu Android Studio gegeben. Jetzt wieder einen Programmiersprachen-Wechsel, aber das passiert alle paar Jahre vielleicht mal. Bei den Web-Technologien kann es sein, dass man bei jeder neuen Technologie, die man einsetzen will, auch ein komplettes System dahinter austauschen muss, wie man die Applikation bestmöglich und modernst möglich entwickelt. Uns geht ja auch immer darum am modernsten Stand zu bleiben und die Dinge auch so zu warten, dass sie weiterhin gut erweiterbar sind und gut entwickelbar sind und den Kunden weiterhin sehr zufriedenstellen.


Isabel:
Ich denke, die meisten unserer App-Projekte, wenn ich das richtig im Kopf habe, sind wirklich Projekte, die sich über mehrere Jahre, also, gezogen haben ist jetzt das falsche Wort, denn natürlich sind die Apps in die Stores gekommen aber sie sind über mehrere Jahre auch wirklich zur Verfügung stehend in den Stores, nicht wahr?


Johannes:
Das ist sicher das Ziel von Applikationen, die wir schreiben für Smartphones und für Mobile Devices – das müssen ja nicht immer nur Smartphones sein. Das können auch Toughbooks sein, die man dann im Außen-Einsatz einsetzt, weil das sind ja dann auch native Apps dann auf diesen Geräten.

Die Kunden, die zu uns kommen, die suchen eben Lösungen, die sie wirklich aktiv in ihren Geschäftsprozessen einsetzen können, die von den Mitarbeitern und Mitarbeiterinnen eingesetzt werden, oder von den Kunden und Kundinnen als Begleit-Produkt, zum Beispiel zu Hardware, wo es dann jahrelang sozusagen auch supportet wird.

Das ist das was der Bernhard gesagt hat. Darum ist es auch für uns ganz wichtig, dass wir Technologie einsetzen, die nicht kurzlebig ist. Also, wo wir sagen können, okay mit einem vertretbaren Aufwand kann man diese Applikation 5, 6 Jahre auch „dastemmen“ von der Wartung her. Was bei Web-Technologien nicht so einfach ist. Also wir haben natürlich Ansätze auch gehabt für einfachere Applikationen, wo auch die Lebensdauer ursprünglich nur für kurze Zeit geplant war, die aber dann – ob man jetzt froh drüber sein kann oder nicht – also, sie waren sehr erfolgreich aber sie waren auf einer falschen Technologie dann gebaut und mussten dann dementsprechend umgewandelt werden und auf neue Beine gestellt werden damit sie auch für lange Jahre wartbar bleiben.


Isabel:
Eine Frage, die ich mir vorstellen könnte, die von den Kunden wahrscheinlich immer kommt oder worüber man sich als Kunde natürlich immer Gedanken macht, ist "Ja, was kost's?". Also sprich: Wie ist es mit einer nativen App, ist es generell teurer diese umzusetzen als eine App auf Web-Technologien?


Harald:
Ja stimmt, im Erstgespräch ist natürlich der Punkt Kosten immer ein Thema. Und was man, welches Bild man schnell mal im Kopf hat ist, für eine mobile App baue ich die App also zweimal – einmal für iOS und einmal für Android, und eine mobile Website hat diesen großen plakativen Vorteil, dass ich sage, ok ich entwickle sie nur einmal, sie steht mir dann auf beiden Plattformen zu Verfügung, also muss doch wohl eine native App zweimal so teuer sein.
Wir haben uns in der Vorbereitung auf diesen Podcast auch intensiv über das Thema auch unterhalten und wie man jetzt auch rausgehört hat aus den Punkten vorher kann man mittlerweile technisch in beiden Varianten wirklich schon relativ viel umsetzen.

Also, entweder habe ich sowieso eine Geräte-Eigenschaft, die mich "zwingt" eine native App zu entwickeln. Wenn ich dort nicht bin, habe ich die freie Möglichkeit oder es ist eben technisch möglich es in beiden Plattformen schön zu implementieren und man muss es sich dann in Wahrheit im Detail anschauen. Als "Faustregel" kann man vielleicht sagen, je höher der Komplexitätsgrad, also je technisch komplizierter die Feature-Wünsche oder auch die Geräteeigenschaften sind, desto höher ist der Aufwand, das mobil zu entwickeln. Demgegenüber kann man stellen, dass die nativen Eigenschaften natürlich von den nativen Plattformen besser unterstützt werden.

Sprich, man dort einen geringeren Aufwand entgegenstellt. Also pauschal kann man das sicher nicht beantworten und genau an so einer Konzeptionsphase am Anfang versuchen wir dann mit unseren Kunden gemeinsam herauszufinden, ein Gespür dafür zu entwickeln, wie komplex ist es und und was bedeutet das, das in Mobil umzusetzen oder was bedeutet das nativ umzusetzen und da in der Regel je komplexer es ist, desto eher rücken die Gesamtkosten dann wieder zusammen oder ist native App dann einfach auf die bessere Wahl.


Isabel:
Wir haben jetzt eine ganze Menge dazu zugehört, zu dem Thema native App oder nicht. Würde sich jemand von euch jetzt trauen, eine schöne Zusammenfassung zu machen oder eine Antwort auf die Frage zu gehen "Machen native Apps überhaupt noch Sinn?".


Johannes:
Also, ich werde einen Versuch starten, eine schöne Zusammenfassung zu machen. Wir haben jetzt sehr viel gehört, was die Gründe sind für iOS, Android nativ zu entwickeln, welche Komplexitätgrade es von Applikationen gibt, welche Arten oder Anforderungen von Kunden es gibt, die uns dazu führen oder wo es für uns als Experten sinnvoll erscheint, native Applikationen zu bauen. Also, wir haben z.b. gehört, dass Applikationen, die jetzt mehr Arbeits-Applikationen sind, wo man die täglichen Tätigkeiten durchführt, dass die nativ sehr gut angesiedelt sind, weil sie ja auf lange Zeit ausgelegt sind, wartbar sein müssen. Die Wartbarkeit, da geht es immer sehr stark um Sicherheit, weil wenn man Applikationen nicht updatet dann hat man natürlich die Gefahr, dass durch nicht entdeckte Sicherheitslücken von den Plattformen – sei es jetzt Web oder nativ – dass man hier dann Gefahr hat, dass von außen jemand zugreifen kann. Da ist es ganz wichtig, dass man regelmäßig Updates macht und da geht's dann darum, was sind denn die laufenden Kosten für den Betrieb dieser Applikation. Also, da ist es wirklich wichtig, dass man hier auch die Möglichkeit hat, in einfacher und nicht zu komplizierter Art und Weise auch die Wartung und den Support zu Verfügung zu stellen. 

Das mit der Offline-Fähigkeit haben wir gehört. Ja, die nativen Apps waren immer schon ausgelegt auf eine Offline-Fähigkeit, wo jetzt auch web nachzieht aber da ist immer noch die native Version performanter und auch einfacher zu implementieren. Alles was jetzt mit der Usability zu tun hat und mit der Interaktivität mit den Geräten wurde von den großen Plattform-Betreibern Android und iOS bis aufs kleinste Detail getestet und ausprobiert mit Millionen von Menschen und da ist es natürlich sinnvoll, sich an die Guidelines von diesen großen Unternehmen zu halten und die Erfahrungen, die sie da gesammelt haben, auch für die eigene Applikation zu nutzen und da macht natürlich auch native Entwicklung den meisten Sinn.

Ja, wenn es darum geht, ist nativ teurer oder kostet mehr oder ist billiger, dann ist es gar nicht so leicht zu beantworten weil es sehr stark auf die Komplexität und Lebensdauer von den Applikationen ankommt.


Isabel:
Danke für die Zusammenfassung Johannes! Damit sind wir am Ende dieses Podcast angelangt. Vielen Dank liebe Kollegen, Harald, Bernhard und Johannes fürs Mitmachen. Ihnen, liebe Zuhörerinnen und Zuhörer, herzlichen Dank fürs Zuhören!