Ich wollte aufschreiben, was ich im Dezember 2021 für die Gründe halte, damit wir sie gelegentlich in der Zukunft noch einmal betrachten und sehen können, ob diese Gründe noch relevant sind. Ich bin selbst ein Web-Typ, daher bin ich daran interessiert zu sehen, wie sich das Web weiterentwickeln kann, um diese Bedenken zu mildern.
Ich konzentriere mich ausschließlich auf Gründe, warum eine native App entweder ein deutlicher Vorteil sein könnte oder zumindest wie ein Vorteil im Vergleich zu einer Website empfunden wird. Nichts Subjektives hier, wie "schneller zu entwickeln" oder "native Apps sind intuitiver" oder ähnliches, was zu subjektiv ist, um es zu quantifizieren. Ich gehe auch nicht auf Gründe ein, bei denen das Web den Vorteil hat. Aber falls Sie unsicher sind, gibt es viele: Es ist eine offene standardisierte Plattform, sie wird geschlossene Systeme überdauern, sie legt großen Wert auf Abwärtskompatibilität, jeder kann für das Web entwickeln, sie läuft plattformübergreifend, und hey, allein URLs sind Grund genug, um zuerst auf das Web zu setzen. Aber das soll nicht heißen, dass native Apps nichts extrem Überzeugendes zu bieten haben, daher dieser Beitrag.
Weil sie ein Icon auf dem Homescreen des Geräts haben.
Es geht um „Mindshare“. Man nimmt sein Handy, das Icon starrt einen an und bittet darum, geöffnet zu werden. Ein weit zitierter Bericht von vor ein paar Jahren besagt, dass 90% der Handynutzung in Apps stattfindet (im Gegensatz zu einem mobilen Webbrowser), auch wenn es hier viel anerkannte Grauzonen gibt. Theoretisch kann man also zu diesen 90% gehören, wenn man eine App erstellt, anstatt in die traurige 10%-Zone verbannt zu werden.
Wenn Reichweite die oberste Priorität hat, scheint die beste Strategie zu sein, *sowohl* eine Web-App als auch eine native App zu haben. So profitieren Sie von der Teilbarkeit und Suchbarkeit, die URLs bieten, zusammen mit einer starken Präsenz auf dem Gerät.
Wenn ich mir den Homescreen meines eigenen Handys ansehe, ist die überwiegende Mehrheit der Apps sowohl nativ als auch Web-Apps: Google Kalender, AccuWeather, Google Maps, Spotify, Notion, Front, Pocket Casts, Instagram, Discord, Twitter, GitHub, Slack und Gmail. Das sind viele große Player, die beides tun.
Mögliche Lösung: Sowohl iOS als auch Android bieten Optionen zum „Hinzufügen zum Home-Bildschirm“ für Websites. Es ist nur eine ziemlich „versteckte“ Funktion, und es ist unwahrscheinlich, dass sie von vielen Leuten genutzt wird. Chrome unter Android geht einen Schritt weiter und bietet eine native App-Installationsaufforderung für Progressive Web Apps (PWAs), die eine Handvoll zusätzlicher Kriterien erfüllen, wie z. B. dass die Website mindestens 30 Sekunden lang genutzt wurde. Native App-Installationsaufforderungen sind ein wichtiges Werkzeug, das dieses Spielfeld ebnet, und es wäre ideal, wenn Apple PWAs besser unterstützen und dies anbieten würde. Als Website-Autoren können wir nicht viel tun; wir warten und hoffen, dass mobile Betriebssysteme es besser machen. Es gibt auch die ganze Welt der Software-Tools, bei denen das, was Sie erstellen, sowohl als Web-App als auch als native App ausgeliefert werden kann, wie z. B. Flutter.
Weil sie schnell starten.
Native Apps verfügen über einen Großteil der Ressourcen, die zum Ausführen der App lokal benötigt werden, was bedeutet, dass sie beim Öffnen keine aus dem Netzwerk abrufen müssen.
Mögliche Lösung: Das ist zunächst nur teilweise wahr. Wenn Sie die App herunterladen, laden Sie die Ressourcen herunter, genau wie das Web. Das Web cacht Ressourcen standardmäßig und bietet durch Service Workers fortschrittlicheres Caching. PWAs sind hier wettbewerbsfähig. Native Apps sind nicht automatisch schneller.
Weil es für Benutzer schwieriger ist, Werbung zu blockieren, und einfacher Daten zu sammeln.
Es gibt alle möglichen Ad-Blocker für Mobilgeräte.
Android Ad Blocker
Aber die funktionieren nur in *mobilen Webbrowsern*, nicht in nativen Apps. Wenn Sie Werbung in nativen Apps blockieren möchten... Pech gehabt, nehme ich an? Wenn der Zweck des von Ihnen erstellten Dings darin besteht, Werbung anzuzeigen oder Benutzer zu verfolgen, nun, ich schätze, Sie werden mit einer nativen App besser abschneiden, vorausgesetzt, Sie erzielen die gleiche Art von Traffic wie mit einer Website (was fraglich ist).
Ich bin zögerlich, "weil native Apps sicherer sind" als Grund auf diese Liste zu setzen, da ich als Benutzer so wenig Kontrolle darüber habe, wie Ressourcen geladen werden, dass es sich für mich nicht wie ein *erhöhtes* Sicherheitsrisiko anfühlt. Aber die Tatsache, dass native Apps normalerweise einen Genehmigungsprozess durchlaufen, bevor sie in einem App Store verfügbar sind, bietet ein gewisses Maß an Schutz, das das Web nicht hat.
Mögliche Lösung: Ad-/Tracker-Blocker-Apps mit nativen Apps arbeiten lassen.
Weil Benutzer eingeloggt bleiben.
Das ist ein wichtiger Punkt! Sobald Sie in einer nativen App eingeloggt sind, bleiben Sie normalerweise eingeloggt, bis Sie sich explizit abmelden oder ein besonderes Ereignis eintritt, wie z. B. die Änderung Ihres Passworts auf einem anderen Gerät. Web-Apps scheinen den Login-Status häufiger zu verlieren, als man möchte, und das trägt zu einem unterbewussten Gefühl für die App bei. Speziell für iOS sind clientseitige Cookies auf 7 Tage begrenzt.
Wenn ich meine native Twitter-App öffne, öffnet sie sich einfach und ist einsatzbereit. Wenn ich davon ausgehen müsste, dass eine 30%ige Chance besteht, dass ich mich einloggen muss, würde ich sie sicher *viel* weniger nutzen. (Und hey, das mag eine gute Sache sein, aber ein Unternehmen wird das sicher nicht so sehen.)
Es gibt auch eine etwas umständliche Sache bei Web-Apps: Selbst wenn Sie in Ihrem primären mobilen Browser eingeloggt sind, sind Sie nicht unbedingt in einem anderen In-App-Browser-Kontext eingeloggt – während native Apps Links oft abfangen und immer im nativen App-Kontext öffnen.
Mögliche Lösung: Hier gibt es keine erstaunliche Lösung. Es ist größtenteils Trickserei. Zum Beispiel lange Cookie-Ablaufdaten (sechs Monate sind ungefähr das, was man bekommt, wenn man Glück hat, höre ich). Oder Sie können so etwas tun, dass Sie einen JSON Web Token (JWT) im Speicher behalten und ihn im Hintergrund regelmäßig neu authentifizieren. Es gibt einige andere Lösungen in diesem Thread, viele davon sind für mich etwas zu hoch. Das Anmeldeerlebnis zu vereinfachen ist auch eine Sache, wie die Verwendung von OAuth oder magischen E-Mail-Links, aber es ist einfach nicht dasselbe wie das Gefühl "immer eingeloggt zu sein". Vielleicht können kluge Browser-Leute etwas entwickeln.
Weil die Apps dieses „native Gefühl“ haben können.
Typischerweise bedeutet das: schnell und flüssig, aber auch, dass sie so aussehen und sich anfühlen wie andere Apps auf dieser Plattform. Apple bietet zum Beispiel SwiftUI an, das speziell für die Erstellung nativer Apps mit vorgefertigten Komponenten entwickelt wurde, die nach Apple aussehen. Das alles im Web zu replizieren, wird schwierig sein. Man muss sich den Hintern abarbeiten, um es so gut zu machen, wie man es "kostenlos" mit etwas wie SwiftUI bekommt.
Mögliche Lösung: Mobile Plattform-Ersteller könnten UI-Kits anbieten, die die Designsprache dieser mobilen Plattform ins Web bringen. Das hat Google weitgehend mit Material gemacht, obwohl die Web-Version noch nicht einsatzbereit ist und nur als "geplante" Veröffentlichung gilt.
Weil sie sich keinen virtuellen Raum mit Konkurrenten teilen, die nur einen Tipp entfernt sind.
Es gibt die Meinung, dass ein Webbrowser die wilde Grenze ist, da man nicht kontrolliert, wohin die Benutzer abwandern können. Wenn sie in Ihrer nativen App sind, ist das gut, dort wollen Sie sie haben. Wenn sie sich in einem Webbrowser befinden, teilen Sie sich Territorium mit unzähligen anderen Apps, anstatt sie auf Ihrem heiligen Boden zu halten.
Mögliche Lösung: Akzeptieren Sie es. Zu versuchen, die Existenz von Konkurrenten zu verbergen, ist keine gute Geschäftsstrategie. Die Stärke des Webs liegt darin, auf einer gemeinsamen, standardisierten, offenen Plattform herumhüpfen zu können.
Weil sie den vollen Funktionsumfang von APIs erhalten.
Alles, worauf das Web hoffen kann, ist der gleiche API-Zugriff wie bei nativen Apps. Zum Beispiel Zugriff auf Kamera, Fotos, GPS, Push-Benachrichtigungen, Kontakte usw. Native Apps erhalten die APIs zuerst, und wenn wir Glück haben, Jahre später erhalten wir im Web eine Art von Zugriff.
Entwickler könnten buchstäblich zu einer nativen App gezwungen werden, wenn eine kritische API im Web fehlt.
Ein großes Beispiel sind Push-Benachrichtigungen. Sind sie im Allgemeinen nervig? Ja, aber es ist eine stark genutzte API und oft eine geschäftliche Anforderung. Und sie ist für viele Apps sinnvoll ("Deine Runde kommt in 500 Fuß", "Dein Fahrer ist da", "Ihr Gepäck kommt auf Karussell 9 an", usw.). Wenn es entscheidend ist, dass Ihre App gute Push-Benachrichtigungen hat, ist das Web keine Option für Ihre App unter iOS.
Mögliche Lösung: Das Web sollte Funktionsparität mit Geräte-APIs haben und neue APIs sollten gleichzeitig für beide veröffentlicht werden.
Weil es einen App Store gibt.
Hier geht es um Auffindbarkeit. Der einzige App Store auf einer Plattform zu sein bedeutet, dass Sie potenziell kostenlose Aufmerksamkeit für Ihre App bekommen. Wenn Sie das beste Skee-Ball-Spiel für eine Plattform entwickeln, besteht eine gute Chance, dass Sie gute Bewertungen erhalten und bei einer Suche nach "Skee-Ball" in diesem App Store ganz oben stehen und Ihnen den Großteil dieses Nischenmarktes sichern. Das ist eine attraktive Aussicht für einen Entwickler. Die Weite ist im Web viel größer, ganz zu schweigen davon, dass SEO ein schwierigeres Spiel ist und sowohl Werbung als auch Marketing teuer sind. Ein Entwickler könnte sich für eine native App entscheiden, nur weil er dort vom Start weg ein größerer Fisch sein kann als im Web.
Und doch, wenn Sie eine App zum Musikhören entwickeln, werden Sie nie die großen Player übertreffen, besonders wenn die Macher der Plattform eigene Apps zum Konkurrieren haben. Das Web könnte gerade wegen des größeren potenziellen Publikums bessere Möglichkeiten für Apps in stark umkämpften Märkten bieten.
Mögliche Lösung: Web-Apps in App Stores zulassen.
Weil Offline-Unterstützung einfacher ist.
Die einzige Offline-Fähigkeit im Web überhaupt ist über Service Workers. Sie sind wirklich cool, aber ich würde argumentieren, dass sie nicht besonders einfach zu implementieren sind, besonders wenn der Plan ist, sie zu nutzen, um wirklich Offline-Erlebnisse für eine Web-App anzubieten, die sonst stark vom Netzwerk abhängig ist.
Native Apps sind weniger vom Netzwerk für alles abhängig. Die Kernressourcen, die die App zum Laufen bringen, sind bereits lokal verfügbar. Wenn also eine native App das Netzwerk nicht benötigt (sagen wir, ein Spiel), funktioniert sie offline einwandfrei. Selbst wenn sie das Netzwerk benötigt, um optimal zu funktionieren, scheint die Verfügbarkeit der zuletzt gespeicherten Daten ein typischer Ansatz zu sein, den viele Apps verfolgen.
Mögliche Lösung: Die Erstellung von Offline-Web-Apps erleichtern.
Podcast zu diesem Thema
ShopTalk 497: Der Stand nativer Apps und Web-Apps im Jahr 2022 mit Thomas Steiner
Ich bin ein Web-Typ und habe das Gefühl, dass die Entwicklung für das Web für die überwiegende Mehrheit der "App"-Situationen die kluge Wahl ist. Aber ich muss zugeben, die Liste der Gründe, warum ein Unternehmen sich für eine native App entscheidet, ist im Moment dick genug, dass es keine Überraschung ist, dass viele von ihnen es tun. Die erfolgreichsten scheinen beides zu tun, trotz der extremen Kosten, beides zu pflegen. So wie responsives Design erfolgreich verhindert hat, dass wir mehrere Versionen einer Website erstellen müssen, hoffe ich, dass diese komplexe Situation in Richtung einer Situation geht, in der Websites die offensichtliche und einzige Wahl für jede Art von App sind.
Ich denke, es wäre besonders interessant, einige Daten darüber zu sehen, wie viele Entwickler Apps entwickeln und wie viele das Web entwickeln.
Zweitens, was wären die Kosten, wenn Sie für das Web entwickeln im Vergleich zur Entwicklung für native Apps? Wie viel müssten Sie investieren, um anzufangen, Hardware und alles?
Ich denke, das sieht man nicht oft genug, den wahren Kostenvergleich vor und nach der Tatsache. Denn ich habe nicht einmal die Tatsache berücksichtigt, dass man alles über all diese Plattformen wissen muss, um tbw.
Wie würden Sie also das Risiko verteilen, bei einer der beiden Optionen zu bleiben, wenn Sie die Verteilung der genannten iOS- und Android-Entwickler betrachten, wobei Windows oft vernachlässigt wird, aber vorhanden ist.
Ich würde sagen, ein weiterer Grund wäre zuverlässige Speicherung/einfacher Zugriff auf das Dateisystem. IndexedDB kann Daten für eine Website speichern, aber alle Browser behandeln die Langlebigkeit dieser Daten unterschiedlich. Es gibt keine Garantie dafür, dass Ihre Offline-Daten im Web permanent sind.
Was Material Design angeht, gibt es ein produktionsreifes Framework für Angular: https://material.angular.io/ Es hat ein Android-Gefühl mit FAB-Buttons usw.
Danke für das Teilen, das Angular Material sieht auf den ersten Blick ziemlich gut aus. Die Baumkomponente ist beeindruckend.
Vergessen Sie nicht die Kontrolle: Niemand kann Ihre Web-App einschränken, moderieren oder ablehnen, weil sie mit seinem Geschäftsmodell konkurriert.
Eine weitere Sache: Sie können Ihre Web-App mit einem nativen Wrapper in einen App Store hochladen, um (mehr) das Beste aus beiden Welten zu bekommen.
Ein kleiner Nebensatz, es gibt einen „Adblocker“/Firewall, der tatsächlich (nicht alle) In-App-Werbung blockiert: **LockDown**: und er ist kostenlos!
Vergessen Sie nicht, dass wir diesen Artikel von einer Website und nicht von einer App lesen.
Ich weiß nicht, ob es möglich oder erwünscht ist, dass Web-Apps und installierte Apps die gleichen Zugriffsrechte und Grenzen haben. Die Installation einer App repräsentiert die *freie Wahl des Nutzers*, einen bestimmten Dienst näher, zugänglicher zu machen und direkten Zugriff auf die Ressourcen seines Geräts zu haben.
Ich wette, es wird eine Zeit geben, in der exakt derselbe Code die Web-App und die Geräte-App ausführt, und Sie trotzdem eine "Install"-Option haben werden. Und Unternehmen bieten möglicherweise einige "PRO"-Funktionen für die installierte App an, nicht weil diese Funktionen sie erfordern, sondern weil sie möchten, dass Sie sich für ihre App für Ihre ausgewählte Liste entscheiden.
Es gibt ein übersehenes Problem, und zwar, dass die meisten Leute ihre ersten Bildschirme auf einem Handy mit ihren am häufigsten genutzten Apps füllen, wie FB, IG, Google-Apps usw. Ich habe viele Web-Apps installiert, aber sie werden oft vergessen und gehen verloren. Oder sie landen in einem Ordner auf der Startseite, der selten geöffnet wird.
Ich bin überrascht, dass Sie ein iPhone haben, Chris, Sie verpassen Termux und KDE Connect (jetzt in der Beta-Testung bei Apple Flight Test). Termux ist erstaunlich für die Webentwicklung auf einem Handy!
Danke für diesen interessanten Beitrag, viel zu recherchieren und nachzudenken, sehr geschätzt.
Ich meine, es gibt hybride Plattformen wie Capacitor, mit denen Sie den Code einmal schreiben und plattformübergreifend bereitstellen können, und die es Ihnen ermöglichen, bei Bedarf in die native Ebene zu gelangen...
Ich denke, es ist wichtig, ein paar Dinge zu bedenken, die bei solchen Entscheidungen oft vergessen werden.
Es ist wirklich schwierig, Leute dazu zu bringen, eine App auf ihr Handy herunterzuladen. Und selbst wenn es Ihnen gelingt, sie davon zu überzeugen, haben Studien gezeigt, dass die Leute nur eine Handvoll davon wirklich nutzen, die anderen liegen einfach untätig herum (was oft dazu führt, dass das Argument "immer eingeloggt" fehlschlägt).
Zusätzlich dazu schafft die Verwaltung von Apps in App Stores einen Overhead, der oft vergessen wird.
Der Hauptgrund, warum ich als Entwickler lieber eine native App als eine Web-App erstellen würde, ist wahrscheinlich derselbe Grund, warum ich mich manchmal für eine Web-App entscheiden würde. Der Grund ist Apple. Mehr dazu gleich.
Der Hauptvorteil, zuerst auf das Web zu setzen, ist, dass Sie sofort ein Produkt haben, das mit jeder Plattform kompatibel ist.
Der Hauptnachteil von Web-Apps, und der Grund, warum ich gerne nativ entwickeln würde, ist, dass jeder Browser seine Engine unterschiedlich implementiert. Jeder interpretiert diesen HTML- und CSS-Code anders, und ich will nicht derjenige sein, aber ich kann nicht anders, Apple-Geräte sind meiner Erfahrung nach die Orte, an denen das Web am meisten kaputt geht. Der Grund ist nicht ihre Technologie, die ehrlich gesagt gut ist.
Der Grund ist, dass sie sich gegenüber Entwicklern ziemlich mies verhalten. Wenn ich eine Webseite auf einem Apple-Gerät testen möchte, bevor ich sie über das Internet zugänglich mache, muss ich entweder das Apple-Gerät, das ich testen möchte, physisch besitzen (und es gibt allerlei Tricksereien, um eine Seite auf einem iPhone debuggen zu können, wenn mein PC ein Windows-Rechner ist), weil man keinen iOS-Emulator außerhalb eines Apple-Geräts ausführen kann, oder einen Mac-PC besitzen, was den Zweck dessen, warum ich als Entwickler zuerst auf das Web setzen würde, zunichtemacht.
Wenn ich einen Mac besitze, könnte ich genauso gut eine native App für deren Plattform entwickeln. Da ich keinen Mac besitze, setze ich zuerst auf das Web, aber ich habe immer noch buchstäblich keine Möglichkeit, mein Produkt auf einem Apple-Produkt vor der Veröffentlichung zu testen, es sei denn, ich kaufe eines nur dafür, was nicht in meinen Plänen liegt.
Der wichtigste Grund: Web-Apps sind Mist.
Das sage ich als jemand mit mehr als 20 Jahren Webentwicklererfahrung und mehr als 10 Jahren iOS-Entwicklererfahrung.
Hören Sie auf, "der Web-Typ" zu sein. Wenn das einzige Werkzeug, das Sie haben, ein Hammer ist, neigen Sie dazu, jedes Problem als Nagel zu behandeln.
Native ist sowohl in der Entwickler- als auch in der Benutzererfahrung weitaus überlegen. Der einzige Vorteil für "die Web-Typen" ist, dass es weniger zu lernen gibt (außer dass es immer noch etwas zu lernen gibt). Und wer hat Zeit, etwas zu lernen, wenn ein neues Framework um die Ecke lauert, oder?
Wenn Sie also faul sind und den gleichen halbfertigen Mist auf allen Plattformen veröffentlichen wollen, benutzen Sie bitte Web-Technologien, die nie für Apps gedacht waren und immer noch nach Lösungen suchen, die von Anfang an mit SDKs für Probleme existierten.
Wenn Ihnen Ihre UX tatsächlich am Herzen liegt, lernen Sie nativ.
Ja, jeder kann für das Web entwickeln. Und das merkt man.
Sie haben es geschafft, super unhöflich zu sein, ohne einen einzigen Punkt zu machen.
Nativ? Machen Sie es "Store-verteilt", da kaum eine App nativ ist, besonders solche, die leicht eine Website sein könnten, mit Cordova-ähnlichen Technologien gebaut werden und im Grunde eine Website anzeigen, oft bedarfsgesteuert heruntergeladen (um Updates ohne den Store zu ermöglichen).