Ich habe gestern einen ganzen Raum voller Webentwickler gefragt, ob irgendjemand von ihnen wusste, dass FF/Chrome/Opera/Brave/etc. für iOS nicht erlaubt waren, in Bezug auf die Engine-Qualität zu konkurrieren.
Zero hands up.
— Alex Russell (@slightlylate) 25. September 2019
Es lohnt sich, das klarzustellen. Unter iOS gibt es nur eine Browser-Engine: WebKit. Es gibt andere Browser, aber sie dürfen keine eigene Engine (Blink/Gecko) mitbringen. Wenn Sie also Chrome oder Firefox unter iOS verwenden, ist es eigentlich dieselbe Engine, die Safari verwendet, nur etwas weniger leistungsfähig (z. B. funktionieren keine Drittanbieter-Content-Blocker-Apps darin).
Das sollte man als Entwickler wissen. Während Chrome Dinge wie Service Worker in seinem Desktop-Browser und auf anderen Plattformen unterstützt, tut dies die Browser-Engine, die Nicht-Safari-Browsern unter iOS zur Verfügung steht, nicht. Sie haben sie dort nicht. Dasselbe gilt für Firefox.
Ich muss sagen, ich bin überrascht, dass das kein Allgemeinwissen war. Ich erinnere mich, dass es ein regelmäßiger Bestandteil von Android-vs-iOS-Argumenten war, wann immer das aufkam.
Nicht, dass ich derjenige sein will, aber ich dachte, das wäre Allgemeinwissen.
Bei mir genauso, ich schreie das schon seit Jahren. Bin überrascht, dass die EU ihnen nicht an den Hals gesprungen ist.
Ähnliche Erfahrung als Kunde, dem von Kundendienstmitarbeitern jeder Firma, die stark auf ActiveX setzte, "Internet Explorer für Mac" verkauft wurde.
Wie sagt man jemandem, der keine Macht hat: "Aber das sind doch unterschiedliche Engines..."
Mobile Safari unterstützt Service Worker und tut dies (in eingeschränkterem Umfang) seit iOS 11.4: https://caniuse.com/#feat=serviceworkers
Entschuldigung, ich glaube, ich habe das missverstanden. Safari unter iOS unterstützt Service Worker; andere Browser-Apps unter iOS unterstützen dies nicht (glaube ich?).
Ja, ich denke, das ist richtig. Safari unter iOS tut es, aber nicht die WebKit-Ansicht, die anderen Browsern zur Verfügung steht.
caniuse.com ist in diesem Fall etwas irreführend. Es listet auf, was in iOS Safari unterstützt wird, aber es gibt keine Möglichkeit herauszufinden, was in der eingeschränkten WebKit-Ansicht unterstützt wird, die andere Browser verwenden. Ich wünschte auch, es würde die Fähigkeiten des Browsers in der Facebook-App unter Android auflisten.
Dafür mag es Gründe geben... siehe https://daringfireball.net/linked/2019/09/25/mr-macintosh-chrome-updater
Wie ist das kein Kartellrechtsfall?
Dafür mag es gute und schlechte Gründe geben. Zum Beispiel testen Sie Ihre Website einmal auf Safari auf einem beliebigen iOS-Gerät und Sie können sicher sein, dass sie auf allen Browsing-Apps auf allen iOS-Geräten funktioniert. Das hat einen gewissen Wert, finde ich.
Nicht, dass ich das wettbewerbsfeindliche Verhalten von Apple verteidigen will, aber es gibt auch Vorteile.
Testen Sie Ihre App auf Chrome unter Windows und Sie haben keine Ahnung, ob Ihre App auf einem anderen Betriebssystem funktioniert... Nicht gerade toll.
Außerdem – wenn Safari etwas kaputt macht, können Sie Kunden nicht bitten, einen anderen Browser zu verwenden, bevor Sie es reparieren. Kunden sind im Arsch. Sie sind im Arsch.
Service Worker sind nicht die einzigen Dinge, die im Rahmen dieses Prozesses untergehen werden. WebKit unterstützt browserbasierte AR/VR, aber Sie müssen es über Safari und nicht über Firefox/Chrome unter iOS ausführen.
Dadurch können Tools wie A Frame, AR.js und 8th Wall nicht ausgeführt werden, es sei denn, sie laufen über Safari.
Wahrscheinlich dieselben Ingenieure, die seit zehn Jahren PWAs als Zukunft anpreisen.