Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

Apple verkündet weitreichende Änderung: iOS-Apps direkt via Webseiten anbieten wird erlaubt

Ein häufiger Kritikpunkt an Apple bezüglich der EU-seitigen Öffnung von Technologien bzw. Plattformen lautet, viel Energie sei in das Ziel geflossen, die Nutzbarkeit so schlecht und umständlich wie nur irgendwie möglich zu gestalten. Das Unternehmen ziehe jegliche Register, unverändert Konkurrenten zu behindern und die überaus lukrativen Gebühren des App Stores als Milliardengeschäft beizubehalten.

Die neuerliche Ankündigung, fortan vertrauenswürdigen Entwicklern zu erlauben, ihre iOS-Apps über einen eigenen Web-Store verkaufen zu dürfen, wirkt zunächst wie eine zusätzliche Lockerung und große Freiheit. Für Hersteller mit einer einzigen, sehr erfolgreichen App, mag das auch durchaus so sein – für Marktplätze hat sich die Situation hingegen weiter verschlechtert.


Die Voraussetzungen für direkten Vertrieb
Um sich den Zwischenweg über einen zusätzlichen Marktplatz zu ersparen, müssen mehrere Voraussetzungen erfüllt sein. Dazu zählen neben dem steuerlichen Sitz in der EU und mindestens zwei Jahre Mitgliedschaft im Entwicklerprogramm auch mindestens eine Million Downloads im abgelaufenen Jahr. Entwicklern mit geringerer Stückzahl bleibt der Weg, ungeachtet ihres Umsatzes, schlicht versperrt.

Apples Taktik: Marktplätze unattraktiver machen
Es ist jetzt attraktiver geworden, Apps direkt anzubieten, anstatt beispielsweise in einen Epic App Store oder Microsoft App Store zu gehen bzw. einen App Store mit nur einer einzigen App auf die Beine zu stellen. Für die erste Million Downloads fallen durch Web-Distribution nämlich keine 50 Cent "Core Technology Fee" pro jährlichem Download pro Nutzer an – wohl aber, wenn ein alternativer Marktplatz zum Einsatz kommt. Apples Strategie dürfte sicherlich lauten, Betreibern von Marktplätzen so die Chance zu nehmen, durch sehr bekannte Apps hohe Nutzerzahlen anzuziehen. Im Falle von Ein-App-Unternehmen wie Spotify wäre es zuvor eine Option gewesen, sich alternativen App Stores anzuschließen, nun wird der Vertrieb ganz sicher nicht über einen Marktplatz erfolgen, sondern eben direkt.

Der Ablauf für Nutzer
Im Hintergrund kommt weiterhin Apples Infrastruktur zum Einsatz, inklusive Überprüfung der App in einem vereinfachten Verfahren ("Notarization Review") sowie Abwicklung von Downloads und Updates. Anwender müssen in den Systemeinstellungen zudem jeden einzelnen externen Entwickler manuell erlauben, andernfalls ist kein Download möglich. Bei der Installation erscheint anschließend ein Sheet mit allen relevanten Informationen, ähnlich den App-Details, wie man sie im iOS App Store kennt. Der wesentliche, sichtbare Unterschied besteht darin, keinen alternativen App Store herunterzuladen, technisch gesehen unterscheiden sich die Vertriebswege ansonsten aber anscheinend nicht. Wirkliches "Sideloading", also Bezug von Apps aus beliebigen Quellen, bleibt weiterhin unterbunden. Es handelt sich daher auch nicht um "Download via Webseite", sondern explizit nur um "Verkauf via Webseite" (über Apples Anbindung).

Zeitplan
Web-Distribution soll im Rahmen eines weiteren Updates zu einem "späteren Zeitpunkt im Frühjahr" eingeführt werden. Es wäre somit durchaus möglich, bis zur WWDC warten zu müssen – der Juni-Termin ist in Apples üblicher Bezeichnungsweise noch "Spring" zuzuordnen. Wie auch bei allen anderen DMA-relevanten Änderungen beziehen sich die Anpassungen ausschließlich auf iOS, nicht jedoch iPadOS und auch nicht auf Länder außerhalb der EU.

Kommentare

andreasm12.03.24 14:19
steuerlichen Sitz in der EU
Die einschlägigen Pornoportale sind dann wohl raus?

Abgesehen von dieser jux und dollerei: wie funktioniert bei diesem Vertriebsweg dann die Updategeschichte?
+2
Mendel Kucharzeck
Mendel Kucharzeck12.03.24 14:27
andreasm
Bisheriger Kenntnisstand: Genau wie im App Store und genau wie auf alternativen Marktplätzen.
+4
Retrax12.03.24 14:27
Also verstehe ich das richtig:

Man könnte dann native iOS-Apps direkt von einer Entwicklerseite laden.
Es geht also nicht um Web-Apps sondern um native iOS-Apps.
Das finde ich interessant, aber aufgrund der auferlegten Regularien für den Verbraucher wohl eher nicht so wirklich effizient und effektiv.

@andreasm
naja vermutlich in etwa so wie Third Party Apps welche nicht im Mac App Store sind auf macOS auch. Entweder kann man in den App-Einstellungen automatisch nach einem bestimmten Intervall nach Updates suchen und installieren lassen oder man schaut manuell auf der Webseite vorbei ob eine neuere Version verfügbar ist.
-1
sYn12.03.24 15:23
Retrax
Also verstehe ich das richtig:

Man könnte dann native iOS-Apps direkt von einer Entwicklerseite laden.

Nein.

Zitat aus dem Artikel:
Wirkliches "Sideloading", also Bezug von Apps aus beliebigen Quellen, bleibt weiterhin unterbunden. Es handelt sich daher auch nicht um "Download via Webseite", sondern explizit nur um "Verkauf via Webseite"
+10
Tommy1980
Tommy198012.03.24 16:16
Herrgott! Hoffentlich setzen sich zeitnah PWAs durch damit dieser HeckMac ;D. endlich aufhört. Das wäre für uns Endkunden auch die beste Lösung. Ja, man bekommt PWA auch genau so sicher oder unsicher auf ein System wie eine native App. Diese Stimmen mögen bitte gleich stumm bleiben. Danke, Gerne.
+2
Zacks
Zacks12.03.24 18:52
Bitte endlich Emulatoren
Ware wa messiah nari!
0
tjost
tjost13.03.24 06:45
Tommy1980
Herrgott! Hoffentlich setzen sich zeitnah PWAs durch damit dieser HeckMac ;D. endlich aufhört. Das wäre für uns Endkunden auch die beste Lösung. Ja, man bekommt PWA auch genau so sicher oder unsicher auf ein System wie eine native App. Diese Stimmen mögen bitte gleich stumm bleiben. Danke, Gerne.

Ohne einer echten Aussage anderen gleich den Mund verbieten finde ich vermessen.

Ob sicher oder unsicher ist auch nur ein Punkt. Datenschutz ein ganz anderer.
0
Dunkelbier13.03.24 07:22
Tommy1980
Herrgott! Hoffentlich setzen sich zeitnah PWAs durch damit dieser HeckMac ;D. endlich aufhört. Das wäre für uns Endkunden auch die beste Lösung. Ja, man bekommt PWA auch genau so sicher oder unsicher auf ein System wie eine native App. Diese Stimmen mögen bitte gleich stumm bleiben. Danke, Gerne.
Ich möchte native Apps, die die Vorteile von macOS (oder Windows) voll nutzen können. Genau das gleiche gilt für diesen lausigen Crossplatform-Mist, der immer mehr um sich greift.
+2
Raziel113.03.24 09:21
Tommy1980
Herrgott! Hoffentlich setzen sich zeitnah PWAs durch damit dieser HeckMac ;D. endlich aufhört. Das wäre für uns Endkunden auch die beste Lösung. Ja, man bekommt PWA auch genau so sicher oder unsicher auf ein System wie eine native App. Diese Stimmen mögen bitte gleich stumm bleiben. Danke, Gerne.

Nachdem Apple PWAs quasi als erstes eingeführt hat und das Interesse daran bis heute eher mau war, ist da auch nicht viel weiter gegangen. Wir hatte damals sogar eine entwickelt, welche nicht nur wie eine native App ausgesehen hat, sondern auch vollständig offline funktionierte mit automatischen updates etc. Da waren wir der Zeit schon echt voraus und das ging alles bereits unter iOS bevor der Begriff PWA per Google und co überhaupt verbreitet wurde, bzw sowas dort überhaupt existierte

Aber obwohl es dann auch durch Google fortgeführt wurde, fand es bis heute nicht so richtigen anklang. Es ist und bleibt halt im Grunde trotztem nur eine Web Applikation und damit technisch auch nicht auf dem Niveau einer "richtigen" App
0
Tommy1980
Tommy198013.03.24 09:25
Aus Entwicklerkreise höre ich halt oft, dass Apple PWA eben bekämpft, weil schadet ja dem Storemodell mit dem sie viel Geld machen. Safari/Webkit hängt halt bewusst dem machbaren hinterher und leider baut Apple wohl immer wieder "versehentlich" Bugs ein, die dann Monate auf einen Fix warten. Ich bin kein Entwickler, kann es daher selbst nicht beurteilen. Habe aber viele im Freundes, Bekannten und Kollegenkreis und diejenigen die mit Safari und PWA etc zu tun haben berichten mir alle diesbezüglich das selbe.
0
Raziel113.03.24 09:32
Tommy1980
Aus Entwicklerkreise höre ich halt oft, dass Apple PWA eben bekämpft, weil schadet ja dem Storemodell mit dem sie viel Geld machen. Safari/Webkit hängt halt bewusst dem machbaren hinterher und leider baut Apple wohl immer wieder "versehentlich" Bugs ein, die dann Monate auf einen Fix warten. Ich bin kein Entwickler, kann es daher selbst nicht beurteilen. Habe aber viele im Freundes, Bekannten und Kollegenkreis und diejenigen die mit Safari und PWA etc zu tun haben berichten mir alle diesbezüglich das selbe.

Das kann ich zumindest so nicht bestätigen. Sonst hätten sie es damals nicht erst eingeführt. Unsere Erfahrung mit Apples Webkit waren eigentlich äussert positiv, gerade eben wegen der berechenbaren konsequenten Updatezyklen. Im Gegenpart hatten wir dann bei Chrome ständig Problem, weil sie meisten experimentelle Features eingebaut haben die nichtmal definiert waren. Teilweise wurden sogar absichtlich Bugs eingebaut mit der Begründung "Man wolle sich dem Verhalten anderer Browser anpassen" und der klare Ansage, das man diese absichtlich eingebauten Bug nicht fixen wird. (Der damals dazu führte, das ganze Kundenprojekte von heute auf morgen nicht mehr funktioniert haben... zumindest bis man einen Workaround fand).

Geredet wird halt viel online. Und Vorwürfe gibts im Grunde ständig in alle Richtungen, meisten mit unterstellter böser Absicht. Dabei waren die Webkit Entwickler sehr Kommunikativ und offen, der Umsetzungsplan offen gelegt und man wusste eigentlich immer wie der aktulle Stand ist die nächsten offiziellen Spec Features umzusetzen.

Aber man muss natürlich schon sagen: Apples Ecosystem und Ziel sind natürlich ein völlig anderes als das von Google. Daher wäre es nicht verwunderlich wenn Google PWAs deutlich offensiver pushed als Apple.
+1
Unwindprotect13.03.24 12:28
Tommy1980
Aus Entwicklerkreise höre ich halt oft, dass Apple PWA eben bekämpft, weil schadet ja dem Storemodell mit dem sie viel Geld machen. Safari/Webkit hängt halt bewusst dem machbaren hinterher und leider baut Apple wohl immer wieder "versehentlich" Bugs ein, die dann Monate auf einen Fix warten. Ich bin kein Entwickler, kann es daher selbst nicht beurteilen. Habe aber viele im Freundes, Bekannten und Kollegenkreis und diejenigen die mit Safari und PWA etc zu tun haben berichten mir alle diesbezüglich das selbe.

Wie so oft ist es eigentlich etwas komplizierter:

Dazu muss man in erster Linie nachvollziehen welches Interesse Google hat. Der Werbe-Monopolist möchte Nutzer weltweit möglichst lückenlos tracken und außerdem viele Möglichkeiten um Werbung anzuzeigen. Schon seit langem trat Google dabei in einer Art auf, als ob "Das Web" ihr eigenes ureigenes Produkt ist... gewissermaßen Googles eigentliche "native" Plattform.

Google hat dazu die entsprechenden Web-Standardgruppen mit zig eigenen Leuten besetzt und zusätzlich durch verschiedene Maßnahmen den eigenen Browser als Quasi-Standard etabliert. Eine dieser Maßnahmen ist, dass man die Webstandard-Gruppen durch die eigenen Mitarbeiter dort mit neuen experimentellen Features quasi "zugesch$%#en" hat. Also: Das Chrome-Team implementiert ohne Absprache mit anderen Feature um Feature und veröffentlicht danach einen "Standard-Artikel" der eingereicht und gepusht wird. Die Browserhersteller müssen dann Aufholjagd spielen... mit einem Feature für das Google vorher beliebig Zeit hatte und das sie natürlich genau so konzipiert haben, dass es in Chrome gut funktioniert. Andere Hersteller müssen schauen wie sie das überhaupt nachbauen können und sie müssen _kompatibel_ sein... es ist immer wesentlich einfacher was eigenes zu machen. Während dieser Aufholjagd ist Chrome aber dann auch der einzige Browser mit dem das coole neue experimentelle Zeug läuft... d.h. die Entwickler die sowas toll finden setzen nochmal mehr auf Chrome. Es erscheinen Seiten die eben vor allem mit Chrome noch gut funktionieren... was wiederrum die Marktmacht des Browsers ausweitet. Das hinterherrennen wird für Browserhersteller dabei immer teurer und man ist hier schlicht Googles Macht in den Standardgruppen ausgesetzt. Microsoft hat sich dem ja nun entzogen indem sie Edge gekillt haben und durch Chrome ersetzt haben... was letztlich ja in Googles interesse ist... denn auch Microsofts Variante trackt noch ordentlich für Google.

Was PWAs angeht, da steckt ein weiterer Aspekt dahinter. Als das iPhone und kurze Zeit später der "AppStore" kamen, sah Google, dass immer mehr Menschen in Zukunft Apps am iPhone verwenden statt Websites am Rechner. Damit verlieren sie die Kontrolle über Tracking und "Werbeflächen". "Android" war die erste schnelle Antwort darauf... ein eigener Konkurrent zu iPhone der insbesondere am Anfang vor allem das iPhone kopiert hat um vor allem durch den billigen Preis und das große Geräteangebot einen größeren Marktanteil zu kriegen. Darüber hinaus hat Google kein besonderes Interesse an Android. Wenn es nach Google ginge dürfte Android auch gerne sterben wenn man es nicht mehr benötigt. Der "Feind" waren ja native Apps. Wenn man es also schafft, dass "Apps" in Zukunft plattformübergreifend als Webanwendungen geschrieben werden, dann ist die Hardware und OS-Plattform völlig irrelevant.

PWA in Form von WebApps die eben ein bestimmtes Set von WebAPIs verwenden (z.B. ServiceWorker) wurden deshalb von Google in Chrome eingebaut und ebenso wieder als Standard durchgeboxt. Das Ziel war schlicht eine "Web-Alternative" zu nativen Apps die beide großen Plattformen umfasst... und dabei gleichzeitig auch noch PCs/Macs. Das Web würde zur einzigen Plattform werden und wie bereits eingangs erwähnt sieht Google sich als alleinigen Besitzer dieser Plattform.

Wie kommt da Apple ins Spiel?

Das Safari-Team bei Apple leidet natürlich wie alle Browserteams darunter, dass das Chrome Team durch ihre Marktmacht einfach Features durchsetzen kann wie sie möchten ohne sich absprechen zu müssen. Dabei ist das Chrome-Team zuletzt sogar so dreist geworden, einfach komplett ohne erst durch irgendwelche Standardgruppen zu gehen bestehende Standards einseitig "abzukündigen". Manche Standards die man gemeinsam entwickelt hat (z.B. Tail Call Optimization in JavaScript) haben sie einfach nicht implementiert und gesagt es sei zu kompliziert das machen sie nicht... nachdem das Safari-Team das bereits implementiert hatte. Für Laien: Tail Call Optimization macht nur Sinn wenn es wirklich in allen Browsern Anwendung findet. Durch die Verweigerung des Chrome-Teams ist dieses Feature also gestorben.

Die verschiedenen PWA Teilstandards waren in ihrer ersten Version so extrem schlecht, dass darin noch zig Sachen unausgegoren und fehlerhaft waren. Viele dieser Fehler wurden von Safari-Entwicklern gefunden! Trotzdem haben "Evangelisten" von Google (also Tech-Lobbyisten) jeden Kanal genutzt um ununterbrochen gegen Apple zu schießen, weil sie u.a. "ServiceWorker" noch nicht implementiert haben.

Tatsächlich hat sich Apple mit der Implementierung von ServiceWorkern und anderen PWA Standards viel Zeit gelassen. Dafür gibt es sicherlich viele Gründe. Einerseits ist es natürlich schwerer eine fremde Spezifikation zu implementieren statt selbst etwas zu machen (wie es Google konnte). Dann waren die Spezifikationen fehlerhaft. Weiterhin sind diese PWA Features auch teilweise Features die eng mit dem Betriebssystem verwoben werden müssen... immerhin geht es ja darum eine Alternative zu "nativen Apps" zu schaffen! Man kann sich also vorstellen, dass das schon viel Aufwand war... vor allem eben unter iOS (für den Mac war es relativ leicht). Google konnte dagegen die PWA Apis sowohl für Chrome als auch Android genau so entwerfen wie es für sie möglichst einfach war.

Last not Least kommt dann _natürlich_ auch der Wettbewerbsaspekt dazu: Wenn Googles Plan mit PWA eigentlich die Vernichtung "nativer Apps" ist, dann sollte es irgendwo klar sein, dass ein Hersteller wie Apple, für den das iPhone und der AppStore wohl die mit wichtigsten Produkte darstellen das nicht gut finden. Inwiefern da dann das Safari-Team möglicherweise gebremst wurde ist natürlich nicht bekannt - aber es ist natürlich vorstellbar. Nichtsdestotrotz haben Safari-Entwickler lange vor Fertigstellung der Features in öffentlichen Foren ob der Fehler in den Spezifikationen diskutiert und sichtlich auf eine Implementierung hingearbeitet... das klingt dann eher wieder nicht danach als ob sie gebremst wurden.

Dennoch bleibt seit dieser Zeit das von Google ständig befeuerte Narrativ, dass "Apple das Web ausbremst oder blockiert". Aus neutraler Sicht würde ich eher behaupten, dass hier zwei Großkonzerne um ihre Marktmacht kämpfen und dabei keiner wirklich besser ist als der andere.
+9
Raziel113.03.24 12:50
So Ziemlich die beste Beschreibung die ich je zu dem Thema gelesen habe 10 Daumen hoch!!
+3
Tommy1980
Tommy198013.03.24 12:55
Raziel1
So Ziemlich die beste Beschreibung die ich je zu dem Thema gelesen habe 10 Daumen hoch!!

Dem möchte ich mich anschließen. Danke dafür. 👍
+2
TotalRecall
TotalRecall14.03.24 23:23
Danke für den informativen Beitrag
Unwindprotect
Tommy1980
Aus Entwicklerkreise höre ich halt oft, dass Apple PWA eben bekämpft, weil schadet ja dem Storemodell mit dem sie viel Geld machen. Safari/Webkit hängt halt bewusst dem machbaren hinterher und leider baut Apple wohl immer wieder "versehentlich" Bugs ein, die dann Monate auf einen Fix warten. Ich bin kein Entwickler, kann es daher selbst nicht beurteilen. Habe aber viele im Freundes, Bekannten und Kollegenkreis und diejenigen die mit Safari und PWA etc zu tun haben berichten mir alle diesbezüglich das selbe.

Wie so oft ist es eigentlich etwas komplizierter:

Dazu muss man in erster Linie nachvollziehen welches Interesse Google hat. Der Werbe-Monopolist möchte Nutzer weltweit möglichst lückenlos tracken und außerdem viele Möglichkeiten um Werbung anzuzeigen. Schon seit langem trat Google dabei in einer Art auf, als ob "Das Web" ihr eigenes ureigenes Produkt ist... gewissermaßen Googles eigentliche "native" Plattform.

Google hat dazu die entsprechenden Web-Standardgruppen mit zig eigenen Leuten besetzt und zusätzlich durch verschiedene Maßnahmen den eigenen Browser als Quasi-Standard etabliert. Eine dieser Maßnahmen ist, dass man die Webstandard-Gruppen durch die eigenen Mitarbeiter dort mit neuen experimentellen Features quasi "zugesch$%#en" hat. Also: Das Chrome-Team implementiert ohne Absprache mit anderen Feature um Feature und veröffentlicht danach einen "Standard-Artikel" der eingereicht und gepusht wird. Die Browserhersteller müssen dann Aufholjagd spielen... mit einem Feature für das Google vorher beliebig Zeit hatte und das sie natürlich genau so konzipiert haben, dass es in Chrome gut funktioniert. Andere Hersteller müssen schauen wie sie das überhaupt nachbauen können und sie müssen _kompatibel_ sein... es ist immer wesentlich einfacher was eigenes zu machen. Während dieser Aufholjagd ist Chrome aber dann auch der einzige Browser mit dem das coole neue experimentelle Zeug läuft... d.h. die Entwickler die sowas toll finden setzen nochmal mehr auf Chrome. Es erscheinen Seiten die eben vor allem mit Chrome noch gut funktionieren... was wiederrum die Marktmacht des Browsers ausweitet. Das hinterherrennen wird für Browserhersteller dabei immer teurer und man ist hier schlicht Googles Macht in den Standardgruppen ausgesetzt. Microsoft hat sich dem ja nun entzogen indem sie Edge gekillt haben und durch Chrome ersetzt haben... was letztlich ja in Googles interesse ist... denn auch Microsofts Variante trackt noch ordentlich für Google.

Was PWAs angeht, da steckt ein weiterer Aspekt dahinter. Als das iPhone und kurze Zeit später der "AppStore" kamen, sah Google, dass immer mehr Menschen in Zukunft Apps am iPhone verwenden statt Websites am Rechner. Damit verlieren sie die Kontrolle über Tracking und "Werbeflächen". "Android" war die erste schnelle Antwort darauf... ein eigener Konkurrent zu iPhone der insbesondere am Anfang vor allem das iPhone kopiert hat um vor allem durch den billigen Preis und das große Geräteangebot einen größeren Marktanteil zu kriegen. Darüber hinaus hat Google kein besonderes Interesse an Android. Wenn es nach Google ginge dürfte Android auch gerne sterben wenn man es nicht mehr benötigt. Der "Feind" waren ja native Apps. Wenn man es also schafft, dass "Apps" in Zukunft plattformübergreifend als Webanwendungen geschrieben werden, dann ist die Hardware und OS-Plattform völlig irrelevant.

PWA in Form von WebApps die eben ein bestimmtes Set von WebAPIs verwenden (z.B. ServiceWorker) wurden deshalb von Google in Chrome eingebaut und ebenso wieder als Standard durchgeboxt. Das Ziel war schlicht eine "Web-Alternative" zu nativen Apps die beide großen Plattformen umfasst... und dabei gleichzeitig auch noch PCs/Macs. Das Web würde zur einzigen Plattform werden und wie bereits eingangs erwähnt sieht Google sich als alleinigen Besitzer dieser Plattform.

Wie kommt da Apple ins Spiel?

Das Safari-Team bei Apple leidet natürlich wie alle Browserteams darunter, dass das Chrome Team durch ihre Marktmacht einfach Features durchsetzen kann wie sie möchten ohne sich absprechen zu müssen. Dabei ist das Chrome-Team zuletzt sogar so dreist geworden, einfach komplett ohne erst durch irgendwelche Standardgruppen zu gehen bestehende Standards einseitig "abzukündigen". Manche Standards die man gemeinsam entwickelt hat (z.B. Tail Call Optimization in JavaScript) haben sie einfach nicht implementiert und gesagt es sei zu kompliziert das machen sie nicht... nachdem das Safari-Team das bereits implementiert hatte. Für Laien: Tail Call Optimization macht nur Sinn wenn es wirklich in allen Browsern Anwendung findet. Durch die Verweigerung des Chrome-Teams ist dieses Feature also gestorben.

Die verschiedenen PWA Teilstandards waren in ihrer ersten Version so extrem schlecht, dass darin noch zig Sachen unausgegoren und fehlerhaft waren. Viele dieser Fehler wurden von Safari-Entwicklern gefunden! Trotzdem haben "Evangelisten" von Google (also Tech-Lobbyisten) jeden Kanal genutzt um ununterbrochen gegen Apple zu schießen, weil sie u.a. "ServiceWorker" noch nicht implementiert haben.

Tatsächlich hat sich Apple mit der Implementierung von ServiceWorkern und anderen PWA Standards viel Zeit gelassen. Dafür gibt es sicherlich viele Gründe. Einerseits ist es natürlich schwerer eine fremde Spezifikation zu implementieren statt selbst etwas zu machen (wie es Google konnte). Dann waren die Spezifikationen fehlerhaft. Weiterhin sind diese PWA Features auch teilweise Features die eng mit dem Betriebssystem verwoben werden müssen... immerhin geht es ja darum eine Alternative zu "nativen Apps" zu schaffen! Man kann sich also vorstellen, dass das schon viel Aufwand war... vor allem eben unter iOS (für den Mac war es relativ leicht). Google konnte dagegen die PWA Apis sowohl für Chrome als auch Android genau so entwerfen wie es für sie möglichst einfach war.

Last not Least kommt dann _natürlich_ auch der Wettbewerbsaspekt dazu: Wenn Googles Plan mit PWA eigentlich die Vernichtung "nativer Apps" ist, dann sollte es irgendwo klar sein, dass ein Hersteller wie Apple, für den das iPhone und der AppStore wohl die mit wichtigsten Produkte darstellen das nicht gut finden. Inwiefern da dann das Safari-Team möglicherweise gebremst wurde ist natürlich nicht bekannt - aber es ist natürlich vorstellbar. Nichtsdestotrotz haben Safari-Entwickler lange vor Fertigstellung der Features in öffentlichen Foren ob der Fehler in den Spezifikationen diskutiert und sichtlich auf eine Implementierung hingearbeitet... das klingt dann eher wieder nicht danach als ob sie gebremst wurden.

Dennoch bleibt seit dieser Zeit das von Google ständig befeuerte Narrativ, dass "Apple das Web ausbremst oder blockiert". Aus neutraler Sicht würde ich eher behaupten, dass hier zwei Großkonzerne um ihre Marktmacht kämpfen und dabei keiner wirklich besser ist als der andere.
0

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.