- Als Reaktion auf den Digital Markets Act (DMA) der EU wurden die Funktionen von iPhone-Web-Apps auf dem Home-Bildschirm eingeschränkt. Epic-Games-CEO Tim Sweeney wirft die Frage auf, ob Apple damit PWAs ausbremsen will, die die Umsätze des App Store gefährden könnten.
- Apple erklärt, man müsse wegen des DMA neben WebKit auch alternative Browser-Engines zulassen; das bisherige Sicherheitsmodell für Web-Apps auf dem Home-Bildschirm habe auf WebKit beruht.
- Dass PWAs in der iOS-Beta für die EU nicht mehr korrekt funktionieren, wurde nicht als einfacher Bug, sondern als absichtliche Änderung von Apple bestätigt. Web-Apps werden damit eher zu Website-Lesezeichen, ohne lokalen Speicher, Badges, Benachrichtigungen und eigenes Fenster.
- Apple sagt, um Web-Apps auf Basis alternativer Browser-Engines sicher zu unterstützen, sei eine neue Integrationsarchitektur nötig, die iOS nicht habe; wegen des Aufwands zur DMA-Umsetzung und der geringen Nutzung habe man sie nicht implementiert.
- Wenn konkurrierende Browser PWAs besser unterstützen als Safari, könnten Web-Apps zu „unbesteuerten“ Konkurrenten nativer Apps werden – Apples Sicherheitsargumentation kollidiert damit mit den Wachstumsaussichten des PWA-Markts.
Eingeschränkte iPhone-Web-Apps auf dem Home-Bildschirm in der EU
- Apple hat bestätigt, dass es die Funktionen von iPhone-Web-Apps in der EU unter Verweis auf die Einhaltung des DMA absichtlich reduziert hat.
- Das Problem wurde sichtbar, nachdem Progressive Web Apps (PWA) in einer aktuellen iOS-Beta für die EU nicht mehr korrekt funktionierten.
- Zunächst wurde ein Beta-Bug für möglich gehalten, doch Apple stellte klar, dass es sich nicht um einen einfachen Fehler, sondern um eine politische Änderung handelt.
- Die entsprechende Erklärung wurde auf Apples Entwickler-Supportseite zum DMA ergänzt.
Apples Logik: ein Sicherheitsmodell auf WebKit-Basis
- Der DMA verlangt von Apple, neben Safaris WebKit auch andere Web-Browser-Engines zu unterstützen.
- Bisherige iOS-Web-Apps auf dem Home-Bildschirm funktionierten auf Grundlage von WebKit und dessen Sicherheitsarchitektur.
- Isolierung des Speichers
- Erzwingen von System-Prompts beim Zugriff auf Funktionen mit Auswirkungen auf die Privatsphäre
- Apple erklärt, ohne diese Isolierung und Durchsetzung könnten bösartige Web-Apps Daten anderer Apps lesen oder unter dem Vorwand der Zustimmung des Nutzers auf Kamera, Mikrofon oder Standort zugreifen.
- In der Folge wurde das iOS-Web-App-Erlebnis für EU-Nutzer stark eingeschränkt; Web-Apps verhalten sich praktisch wie Website-Lesezeichen.
- Kein Support für lokalen Speicher
- Kein Support für Badges
- Kein Support für Benachrichtigungen
- Kein Support für eigene Fenster
Tim Sweeneys Gegenargument: PWAs als potenzielle Konkurrenten des App Store
- Epic-Games-CEO Tim Sweeney schrieb auf X, Apples eigentlicher Grund könnte sein, dass iPhone-Web-Apps Apple keine Umsätze bringen.
- Sweeney ist CEO von Epic Games, das Apple wegen kartellrechtlicher Fragen rund um App-Store-Gebühren verklagt hat; er hat in dieser Angelegenheit also ein klares Eigeninteresse.
- Der Streitpunkt ist, ob Apples Entscheidung eine Maßnahme zum Schutz der Nutzer ist oder eine Entscheidung, eine potenzielle Bedrohung für Apples Geschäft zu verringern.
- Sweeney meint, konkurrierende Browser könnten PWAs deutlich besser unterstützen als Safaris eingeschränkte Web-Funktionen; dann könnten PWAs zu einem „legitimen und unbesteuerten Konkurrenten“ nativer Apps werden.
Technische Lösung vorhanden, Umsetzung aber zurückgestellt
- Apple räumt ein, dass es technische Wege gibt, die Sicherheits- und Datenschutzprobleme von Web-Apps mit alternativen Browser-Engines zu lösen.
- Dafür müsste jedoch eine vollständig neue Integrationsarchitektur aufgebaut werden, die es in iOS derzeit nicht gibt.
- Apple sagt, die DMA-Umsetzung habe bereits „mehr als 600 neue APIs und verschiedene Entwickler-Tools“ erfordert; wegen der sehr geringen Nutzung von Web-Apps auf dem Home-Bildschirm sei der Aufbau dieser Architektur nicht praktikabel.
- Da der DMA eine Regulierung ist, die über Jahre vorbereitet wurde, war diese Änderung für Apple nicht unvorhersehbar.
Behauptung geringer Nutzung kollidiert mit Wachstumsaussichten für PWAs
- Apple verweist auf die geringe Nutzung von Web-Apps auf dem Home-Bildschirm und bewertet die Auswirkungen der Funktionseinschränkung daher als gering.
- In der Vergangenheit hat Apple jedoch Funktionen hinzugefügt, damit PWAs wie native Apps funktionieren und sich leicht außerhalb des App Store verteilen lassen.
- Die Prognosen für den PWA-Markt weisen in eine andere Richtung als Apples Argument der geringen Nutzung.
- Analysten schätzen, dass der PWA-Markt 2027 10,44 Milliarden US-Dollar erreichen wird.
- Die durchschnittliche jährliche Wachstumsrate liegt bei rund 31,9 %.
- Wenn alternative Browser-Engines PWAs nützlicher machen können, könnten Web-Apps zu einer direkten Bedrohung für das App-Store-Geschäft werden.
- Apple reagierte auf eine Bitte um Stellungnahme zur PWA-Entscheidung nicht gesondert, sondern veröffentlichte eine Erklärung auf seiner DMA-Website.
1 Kommentare
Hacker-News-Kommentare
Er hat recht. Apple hat jahrelang die Weiterentwicklung von Web-Apps auf iOS unterdrückt und versucht, die 30-%-Gebühr zu erhalten, indem Web-Apps daran gehindert wurden, mit nativen Apps aus dem App Store zu konkurrieren.
Jetzt, da Apple Browser-Engines von Drittanbietern zulassen muss, könnten Web-Apps deutlich leistungsfähiger werden, aber Apple akzeptiert das nicht und entscheidet sich stattdessen dafür, eine für alle nützliche Funktion abzuschalten.
Das dürfte nach hinten losgehen, und die eigenen Funktionen herunterzustufen, nur um Wettbewerber zu schikanieren, wird den Unmut von Nutzern, Unternehmen, Entwicklern und Gesetzgebern nur weiter vergrößern. Auch Apples Vorschlag zur Einhaltung des Digital Markets Act wirkt eher wie Nicht-Einhaltung, und der DMA verlangt freie Interoperabilität, während Apple eine sehr wettbewerbsfeindliche Gebühr eingeführt hat. Wenn diese wegfällt, können Entwickler die nativen Apps, die sie wollen, frei vertreiben, und zu diesem Zeitpunkt dürften viele Entwickler zu anderen App-Stores wechseln.
Die Leute gehen einfach in den App Store, laden irgendeine Website-App herunter und stören sich nicht daran, selbst wenn es nur eine Browser-App ist, die eine Website rendert. Damit ein Apple-Boykott entsteht, müsste Apple etwas entfernen, das den Leuten tatsächlich wichtig ist.
Obwohl ich wusste, dass es diese Funktion gibt, und sogar Code geschrieben habe, der sie unterstützt, habe ich fast fünf Minuten gebraucht, um den Button zu finden. Sie im Share Sheet zu verstecken, ist wirklich dumm.
Apple hat viele Webfunktionen vorangetrieben, die das Web stärker wie native Apps wirken lassen, und in vielen Fällen Spezifikationen erstellt oder sie früher als andere übernommen. Dinge wie backdrop-filter, position: sticky oder CSS-Snap-Points tragen meiner Ansicht nach deutlich mehr dazu bei, Websites wie native Apps aussehen zu lassen, als Funktionen wie WebMIDI.
In den jüngsten Reaktionen auf den DMA steckt viel böswillige Compliance und Kleinlichkeit, aber ich glaube nicht, dass das Entfernen rahmenloser Home-Bildschirm-Lesezeichen dazu gehörte. Apple hat die Regeln streng ausgelegt und war an dieser Funktion nicht besonders interessiert, also hat man sie eher einfach entfernt.
Apple scheint eine andere Philosophie und andere Prioritäten für die Webplattform zu haben als Chrome, mit stärkerem Fokus auf Datenschutz, Performance und Effizienz.
In den Kommentaren, die ich gelesen habe, wünschen sich viele, dass der DMA kostenlose Interoperabilität verlangt, aber ich weiß nicht, ob das tatsächlich so geregelt ist. Vielmehr scheint er bis zu einem gewissen Grad ausdrücklich zuzulassen, dass Gatekeeper weiterhin Zugangsgebühren verlangen können.
Erwägungsgrund 62 beginnt mit: „Für Software-Anwendungsspeicher, Online-Suchmaschinen und Online-Dienste sozialer Netzwerke, die in dem Benennungsbeschluss aufgeführt sind, sollten Gatekeeper faire, angemessene und nichtdiskriminierende allgemeine Zugangsbedingungen veröffentlichen und anwenden“, dieser Punkt betrifft also App-Stores.
Der zweite Absatz beginnt mit: „Preise oder andere allgemeine Zugangsbedingungen sollten als unfair gelten, wenn sie zu einem Ungleichgewicht der den gewerblichen Nutzern auferlegten Rechte und Pflichten führen, dem Gatekeeper einen Vorteil verschaffen, der in keinem angemessenen Verhältnis zu der von ihm für gewerbliche Nutzer erbrachten Dienstleistung steht, oder zu einem Nachteil für gewerbliche Nutzer bei der Bereitstellung derselben oder ähnlicher Dienste wie der Gatekeeper führen.“
Für mich deutet diese Formulierung darauf hin, dass die Möglichkeit, Gebühren zu erheben, zumindest in Betracht gezogen wird. Ich wäre neugierig, wo https://eur-lex.europa.eu/eli/reg/2022/1925/oj „kostenlose Interoperabilität“ verlangt.
Falls du Artikel 6 Absatz 7 meinst, stimme ich nicht zu. Meiner Ansicht nach geht es dort nur um Dinge wie SDK-Zugang, Spezifikationen von Geräteanschlüssen oder die Fähigkeit, dieselben Systemaufrufe wie Gatekeeper-Anwendungen zu nutzen.
In Artikel 6 Absatz 7 heißt es: „Der Gatekeeper muss Dienstanbietern und Hardwareanbietern in Bezug auf dieselben Hardware- und Softwarefunktionen, auf die über ein Betriebssystem oder einen virtuellen Assistenten zugegriffen wird oder die über ein Betriebssystem oder einen virtuellen Assistenten gesteuert werden, die in dem Benennungsbeschluss nach Artikel 3 Absatz 9 aufgeführt sind, unentgeltliche und wirksame Interoperabilität sowie Zugang zu Interoperabilitätszwecken in demselben Umfang ermöglichen, in dem sie für die vom Gatekeeper bereitgestellten Dienste oder die von ihm bereitgestellte Hardware verfügbar sind. Darüber hinaus muss der Gatekeeper gewerblichen Nutzern und alternativen Anbietern von Diensten, die zusammen mit den zentralen Plattformdiensten oder zu deren Unterstützung erbracht werden, unentgeltliche und wirksame Interoperabilität sowie Zugang zu Interoperabilitätszwecken in Bezug auf dieselben Betriebssystem-, Hardware- oder Softwarefunktionen ermöglichen, die dem Gatekeeper bei der Erbringung solcher Dienste zur Verfügung stehen oder von ihm genutzt werden, unabhängig davon, ob diese Funktionen Teil des Betriebssystems sind.“
Aber angesichts solcher Maßnahmen und der Richtung, die Apple mit SwiftUI einschlägt, bekomme ich wieder Interesse an Web-Apps.
Aus Apples Sicht ist es unglaublich praktisch, dass sich Sicherheitsfunktionen und wettbewerbswidriges Verhalten überschneiden.
Wenn jemand sagt: „Ich will keinen Vendor-Lock-in“, dreht Apple es sofort um zu: „Heißt das, dir ist Sicherheit egal?“
Aber oft ist das eine falsche Dichotomie, die Apple selbst geschaffen hat. Es ist gut, Apps zu prüfen und abzulehnen, um Betrug und Malware zu verhindern, aber Apple hat das damit vermengt, Apps abzulehnen, nur weil sie das Wort „Android“ verwenden, oder die gewünschte eigene Kuratierung durchzusetzen.
Die standardmäßig bereitgestellte First-Party-Abo-UI ist für Nutzer sicher und bequem, aber dank des mobilen Duopols und der Plattformkontrolle kann Apple dafür beliebige Gebühren verlangen. Apple stellt es so dar, als würde die Zulassung anderer Zahlungsabwickler Nutzer auf fragwürdige Websites führen, auf denen Abo-Kündigungen und Rückerstattungen unmöglich sind, doch auch das ist eine von Apple geschaffene falsche Dichotomie. Man könnte alternative Zahlungsabwickler verpflichten, sich in die iOS-API zur Abo-Verwaltung zu integrieren, und PayPal wird bereits als Backend unterstützt.
Auch in diesem Fall kommt es Apple äußerst gelegen, dass es riskant ist, interne APIs ohne Schutzmechanismen für Dritte zu öffnen. Aber man muss Drittanbieter-Browser nicht ohne Sandbox laufen lassen, und man muss nicht jeder beliebigen App erlauben, nach Belieben Homescreen-Icons zu erstellen. „Zum Home-Bildschirm hinzufügen“ ist bereits eine Nutzeraktion über das Share Sheet und wird vom Betriebssystem vermittelt. Browser müssen ohnehin in einer Sandbox laufen, und Web-Apps durften bereits im Vollbildmodus ausgeführt werden.
Das ist nicht einfach nur ein Problem, bei dem irgendeine Funktion fehlt. Apple behauptet seit Jahren, der App Store sei nicht zwingend nötig und jeder könne einfach Web-Apps erstellen. Wegen der Einschränkungen von Safari war das von Anfang an nicht ganz wahr, aber jetzt ist es schlicht eine Farce.
„Stattdessen verleitet die Betrugs-App LassPass dazu, ein ‚Pro‘-Konto-Abo für 2 Dollar pro Monat, 10 Dollar pro Jahr oder 50 Dollar auf Lebenszeit abzuschließen. Für eine Betrugs-App ist das tatsächlich ein niedriger Preis. Viele betrügerische Apps versuchen, etwa 10 Dollar pro Woche zu verlangen.“
Außerdem behauptete er, obwohl er das gar nicht wissen konnte, sie sehe „nicht so aus, als wäre sie darauf ausgelegt, LastPass-Zugangsdaten zu stehlen“. Der ganze Text hatte die Stimmung: „Ja, das ist schlecht und sollte nicht passieren, aber es ist doch keine große Sache. Warum macht ihr Apple so dafür verantwortlich?“
Glaubt Apple wirklich, dass solche Spielchen keine Gegenreaktion auf EU-Regulierung auslösen werden?
Jedes Mal, wenn ich neuen Unsinn dieser Art lese, kocht mein Blut, und meine Haltung gegenüber Apple und anderen riesigen wettbewerbsfeindlichen Unternehmen wird nur noch härter.
Dinge, bei denen einem das Blut kochen sollte, sollten solche sein, denen man im Leben nicht leicht ausweichen kann. Am Ende sind das nur Telefone und Computer, und hier wird Leidenschaft für etwas völlig Bedeutungsloses verschwendet.
Ich wünschte, die Leute, die sich über Apple beschweren, würden statt zu jammern in einen Streik treten und die Entwicklung für Apple-Hardware einstellen.
Noch besser wäre es, wenn sie ihre eigene Hardware bauen würden, die dann nicht die ganze Softwarelast hätte; viele der klagenden Unternehmen sind Milliarden Dollar wert und könnten sich das leisten.
Natürlich werden sie das nicht tun, weil sie wie Apple Geld wollen. Wenn aber Spotify, Epic und andere die Unterstützung für iOS-Geräte einstellen würden, würde Apple wohl darüber nachdenken, sein Verhalten zu ändern.
Wenn Entwickler und Nutzer zu Android wechseln, wird Apple sich ändern. Ist Android wirklich so schlecht, dass man gezwungen ist, iOS zu verwenden?
So wie niemand gern fünf Abos behält, um Zugriff auf Netflix, HBO, Prime, Disney und Hulu zu haben. Es ist schon ein Wunder, dass es wenigstens ein Duopol und kein Monopol gibt.
Diese Leute übernehmen nicht das kleinste bisschen Verantwortung und kaufen den verdammten Kram einfach weiter.
Der Satz „Jetzt verhalten sich Web-Apps wie Website-Lesezeichen, ohne Unterstützung für lokalen Speicher, Badges, Benachrichtigungen und eigene Fenster“ ist für mich der Kern.
Der Zugriff vom Homescreen aus ist nicht vollständig blockiert. Meine einfache Web-App kommt auch ohne Benachrichtigungen und lokalen Speicher aus.
Aber viele Menschen brauchen Progressive Web Apps, daher verstehe ich, dass diese Änderung für sie besonders bösartig ist.
Das ist eindeutig offenkundig mieses Verhalten von Apple, und wenn man faire und freundliche Software unterstützen will, scheint es Zeit zu sein, die Hardware in der eigenen Tasche zu wechseln.
Eine Website im Standalone-Modus ist eine Web-„App“, aber wenn eine Website die Browserleiste nicht loswerden kann, selbst wenn sie alle modernen Webfunktionen nutzt, dann sind Web-Apps in Safari nicht möglich. Dann ist es nur eine Website-Verknüpfung im Tab-Modus.
Außerdem wissen wir noch nicht, welche Webfunktionen Apple auf Websites verbieten will und ob diese Verbote auch für konkurrierende Browser gelten werden.
Unklar ist auch, ob Offline-Websites mit Service-Worker-Caching möglich sein werden. Laut einigen Betatestern scheint es deaktiviert zu sein.
Persönlich mag lokaler Speicher für einen nicht wichtig sein, aber man sollte bedenken, wie groß der Nachteil für Webprogrammierung ist, wenn Apple lokalen Speicher ohne Zustimmung des Nutzers löscht, wie es bei Safari-Tabs der Fall ist.
Fehlende Zukunftssicherheit ist eines der größten Probleme. Denn Webprogrammierung ist eine Strategie, für die sich Unternehmen heute entscheiden, um in 2–3 Jahren gute Web-Apps ausliefern zu können.
Angenommen, Apple hätte PWAs unverändert gelassen, also hart in Safari verdrahtet: Hätten Mozilla oder Microsoft Apple dann nicht sofort wegen eines DMA-Verstoßes verklagt oder die Sache beanstandet, weil sie ihre eigenen Browser-Engines nicht über die vom Nutzer hinzugefügten Homescreen-Icons ausführen können?
Dann wäre es doch ein Risiko astronomischer Geldbußen in der EU gewesen, bestehende PWAs einfach so zu belassen, oder nicht?
Wenn die iOS-Entwickler so unfähig sind, hätte man macOS-Entwickler bezahlen können, damit sie die nötigen Änderungen an einem Wochenende umsetzen. Beide Betriebssysteme sind Unix-artig, macOS kann das definitiv, und Apple hatte Jahre Zeit
Wenn Apple die Karte „zu schwierig“ ausspielen will, muss das Unternehmen nach dem DMA belegen, warum die Belastung so groß ist. In Wirklichkeit ist sie das aber nicht, also kann Apple es nicht belegen. Trotzdem hätte man mit der EU verhandeln und eine Ausnahme bekommen können, damit Safari-Web-Apps nicht kaputtgehen, bis alle Webbrowser bereit sind, Web-Apps unter iOS zu unterstützen
Tatsächlich hat Apple alle iOS-Web-Apps kaputtgemacht, die nur in Safari möglich waren, kämpft dann ein weiteres Jahr mit der EU und erlaubt sie wieder, falls es verliert
Wie kann man sagen, dass das nicht böswillig ist? Apple traut sich das nur, weil derzeit nur wenige Nutzer Web-Apps verwenden
Zu behaupten, es sei schwierig, innerhalb weniger Monate alle Fälle abzudecken, liefert nur eine Ausrede dafür, dass man es so lange verschleppt hat
Nehmen wir an, ich möchte ein kleines Dashboard für meinen Homeserver bauen, das ich auf dem iPhone im Vollbild anzeigen kann. Wenn ich in der EU lebe, wie soll ich das zum Homescreen hinzufügen?
Da es für einen lokalen Server gedacht ist, würde es die Prüfung nicht bestehen, also kann ich es selbst dann nicht in den App Store stellen, wenn ich wollte. Lokale Debug-Builds laufen nach ungefähr einer Woche ab. Was kann man hier tun?
Ich will Apple nicht verteidigen. Ich lehne viele Entscheidungen ab, die einschränken, was ich mit der Hardware tun kann, die ich gekauft habe, einschließlich der „nur WebKit“-Politik. Trotzdem habe ich ein gewisses Verständnis für den aktuellen Zustand von Apple-Produkten, und daher fällt es mir etwas schwer, mit jemandem mitzufühlen, der ein iPhone kauft und genau diese maßgeschneiderte Interoperabilität erwartet
Nichttechnische Nutzer wollen solche Anpassungen mit viel geringerer Wahrscheinlichkeit, und technische Nutzer sollten es besser wissen
Allerdings würde ich mir wirklich wünschen, dass sich das ändert. Es wäre schön, wenn man Universal-Hardware vernünftigerweise tatsächlich als nützlich für allgemeine Zwecke ansehen könnte
PWAs sind perfekt für private und interne Apps. In Europa scheinen ziemlich viele Gesundheitsdienstleister PWAs zu nutzen, um Patientenversorgung anzubieten. Apple macht solche Apps kaputt und zerstört ohne Vorwarnung gespeicherte Nutzerdaten
Es ist ohnehin nicht mehr als ein Link zu einer Webseite
Ich habe noch nie eine PWA implementiert und bin auch kein Apple-Nutzer, daher fehlt mir vielleicht der Kontext. Trotzdem scheint es eine gute Methode zu sein, einfache plattformübergreifende Apps zu entwickeln
Nach meinem Verständnis öffnen sich PWAs nicht mehr im Vollbild und sehen nicht mehr wie native Apps aus, sondern werden jetzt wie Lesezeichen im Browser geöffnet
Aber wenn es einfach eine Webseite ist, sollte sie doch weiterhin „funktionieren“, oder?
Wenn Apple die Benachrichtigungs-API kaputtgemacht hat, gehen Benachrichtigungen natürlich nicht, aber viele Websites nutzen Benachrichtigungen. Ist zum Beispiel auch das Popup in WhatsApp Web zum Aktivieren von Desktop-Benachrichtigungen jetzt kaputt?
Bedeutet „kein lokaler Speicher“ JavaScripts sessionStorage/localStorage? Wenn man das kaputtmacht, würden viele Websites kaputtgehen. Den Cookie-Speicher kann man doch nicht einfach so zerstören?
PWAs sehen dann zwar nicht wie glatt polierte Apps aus, aber für ein einfaches persönliches Dashboard scheint das kein großes Problem zu sein
Die HTML/JavaScript-API erlaubt Vollbild
Apple soll gesagt haben, „bösartige Web-Apps können Daten anderer Apps lesen und mit Zustimmung des Nutzers auf Kamera, Mikrofon und Standort zugreifen“; die Erklärung lautet also, dass man wegen der DMA-Anforderung, alternative Browser-Engines zu erlauben, das iOS-Web-App-Erlebnis für EU-Nutzer verschlechtert habe, um Nutzer vor Risiken zu schützen
Aber der Zugriff auf Kamera, Mikrofon und Standort des Nutzers ist weiterhin möglich. Schon seltsam
Irgendjemand wird diese Logik sicher glauben
Epic entwickelt meines Wissens keine PWAs, daher ist das eher ein allgemeiner Vorwurf in Richtung Apple
Trotz Apples dominanter Stellung kann ich den Wunsch nachvollziehen, die Angriffsfläche zu reduzieren und eine Funktion zu entfernen, die nur von einer winzigen Minderheit genutzt wurde. PWAs liegen in einem Graubereich zwischen normalen Web-Apps und vollwertigen Apps. Normale Web-Apps kann man meines Wissens ebenfalls auf dem Homescreen als Lesezeichen ablegen, Ressourcen über E-Tag- und Cache-Control-HTTP-Header cachen, und localStorage gibt es auch
Mir ist nicht klar, worin der genaue Vorteil von PWAs gegenüber normalen Web-Apps besteht. Können sie so etwas wie dauerhaft aktives Server-Push empfangen? Aber wie viele Nutzer wollen das tatsächlich?
Persönlich habe ich nie PWAs genutzt oder erstellt. Wenn ich native iOS- oder Android-Ziele ansprechen will, setze ich wie ein normaler Mensch ein React-Native-Projekt auf
Ich greife Apples monopolistische Praktiken genauso gern an wie jeder andere, aber dieser Fall wirkt übertrieben. PWAs sind so etwas wie das uneindeutige Bastardkind der Web-App-Entwicklung, und es ergibt Sinn, die Unterstützung einzustellen, um das Betriebssystem und die zugehörigen APIs zu vereinfachen
Es nervt, dass Gespräche ständig von Leuten gekapert werden, die selbst nicht mit Steinen werfen sollten, und dass Dinge, die gar keine Kontroverse sein müssten, zu einer „Kontroverse“ werden