Letzte Woche erntete ich noch eines dieser "Wirklich?!" 🤨 Gesichter, als diese Tatsache in einer Unterhaltung unter intelligenten und engagierten Webentwicklern aufkam: Es gibt keine Browserwahl auf iOS. Es ist alles Safari. Man kann Apps herunterladen, die *Chrome* oder *Firefox* oder irgendetwas anderes *heißen*, aber sie sind nur eine Fassade über Safari. Wenn man eine Website auf iOS betrachtet, ist es Safari.
Ich sollte es wohl so nennen, wie es die App Store Review Guidelines nennen: WebKit. Normalerweise halte ich es für klarer, Browser anhand ihrer gängigen Namen statt der dahinterliegenden Engine zu bezeichnen, da jeder der drei großen Webbrowser seine eigene Engine hat (zumindest für den Moment). In diesem Fall ist die Engine aber der wichtige Teil.
Ich sage, wie ich es empfinde: Das ist Mist. Ich habe diesen teuren Computer in meiner Tasche und es fühlt sich unfair an, dass er auf diese sehr spezifische Weise eingeschränkt ist, indem andere Browser-Engines nicht erlaubt sind. Ich habe auch einen Apple-Laptop, und der ist auf diese Weise nicht eingeschränkt. Ich hoffe sehr, dass das nie der Fall sein wird.
Es gibt natürlich allerlei Nuancen dazu. Mein Apple-Laptop ist insofern eingeschränkt, als dass ich nicht einfach jedes beliebige Betriebssystem installieren kann, es sei denn, ich tue es auf eine genehmigte Weise. Mir gefällt auch die Tatsache, dass es bei iOS-Apps eine gewisse Zugangskontrolle gibt, und manchmal wünschte ich, sie wäre *strenger*. Zum Beispiel, wenn ich einfache Spiele für mein Kind herunterladen möchte und dann ein Spiel herunterlade, das so voller Upsells, Werbung und dunkler Muster ist, dass ich denke, der Entwickler gehört ins Gefängnis. Ich wünschte, Apple würde solchen Müll überhaupt nicht im App Store zulassen. Also wünsche ich mir gleichzeitig mehr und weniger Zugangskontrolle.
Aber was an diesem Mangel an Browserwahl auf iOS schlecht ist, ist nicht nur die Philosophie der Zugangskontrolle, sondern dass WebKit auf iOS einfach nicht so toll ist. Siehe Daves Beitrag für eine Zusammenfassung einiger Probleme aus der täglichen Perspektive eines Webentwicklers, die ich nachvollziehen kann. Und weil WebKit auf iOS buchstäblich keine Konkurrenz hat, *weil Apple keine Konkurrenz zulässt*, ist der Anreiz, Safari zu verbessern, *viel geringer*, als er sein könnte (sollte).
Das ist nicht so wie Googles AMP, wo man, wenn es einem wirklich nicht gefällt, es nicht auf den eigenen Websites verwenden und sich auf anderen Websites davon wegleiten kann. Diese Entscheidung wird für Sie getroffen.
Meine Fähigkeit, intelligent darüber zu sprechen, wird jedoch von vielen anderen übertroffen, daher möchte ich vor allem auf einige der neueren Veröffentlichungen hinweisen. Erlauben Sie mir, ein Zitat aus einigen davon zu ziehen…
iOS Engine Choice In Depth — Alex Russell
Nichts davon ist theoretisch; die Notwendigkeit, Funktionen durch ein Strohhalm neu zu entwickeln, unter Verwendung von weniger sicheren, schlechter getesteten und analysierten Mechanismen, hat zu ernsthaften Sicherheitsproblemen bei alternativen iOS-Browsern geführt. Apples Politik schützt verantwortungsbewusste WebKit-Browser keineswegs vor Sicherheitsproblemen, sondern ist ein wahrer Fehlerteufel für die Projekte, die zwischen dem verarmten Funktionsumfang von Apples WebKit und den Funktionen, die sie mit hoher Wiedergabetreue auf jeder anderen Plattform sicher liefern können, eingeklemmt sind.
Dies ist natürlich ein ernstes Problem für Apples Argumentation, warum es allein für die Bereitstellung von Updates für Browser-Engines auf iOS verantwortlich sein sollte.
Chrome is the new Safari. And so are Edge and Firefox. — Niels Leenheer
Das Safari- und das Chrome-Team wollen beide das Web sicherer machen und arbeiten hart daran, das Web zu verbessern. Aber sie haben unterschiedliche Ansichten darüber, wie das Web sein sollte.
Google konzentriert sich darauf, das Web durch mehr Möglichkeiten zu verbessern. Die Relevanz des Webs zu erweitern, über das hinaus, was heute möglich ist. Und das bedeutet auch, dass es mit nativen Apps konkurrieren kann, womit das Android-Team sicherlich nicht immer einverstanden ist.
Safari scheint sich darauf zu konzentrieren, das Web so zu verbessern, wie es gerade ist. Damit es ein sichererer Ort ist, viel schneller und schöner. Und wenn man mehr will, kann man eine App dafür nutzen.
Browserwahl auf Apples iOS: Datenschutz- und Sicherheitsaspekte — Stuart Langridge
Alternative Browser auf iOS sind nicht nur auf WebKit beschränkt, sie sind auf die Version von WebKit beschränkt, die in der aktuellen Version von Safari enthalten ist. Nicht einmal andere oder modernere Versionen von WebKit selbst sind erlaubt.
Selbst motivierte Benutzer, die hart daran arbeiten, aus der erzwungenen Browserwahl auszubrechen, haben keine wirkliche Wahl; wenn sie einen anderen Browser wählen, erhalten sie immer noch denselben. Wenn es eine Anforderung von Menschen gibt, kann der Markt diese nicht erfüllen, da Wettbewerb nicht erlaubt ist.
Briefing to the UK Competition and Markets Authority on Apple’s iOS browser monopoly and Progressive Web Apps — Bruce Lawson
[…] diese Leute von Echo Pharmacy, sie haben nicht nur eine wirklich tolle Website, sondern sie müssen auch eine App für iOS bauen, nur weil sie Push-Benachrichtigungen senden wollen. Und, vielleicht ironischerweise, angesichts von Apples Beharren darauf, dass sie all dies für Sicherheit und Datenschutz tun, ist, dass wenn ich diese App installieren würde, ich ihr auch die Erlaubnis erteilen würde, auf meine Gesundheits- und Fitnessdaten, meine Kontaktinformationen, meine sensiblen Identifikationsdaten, Finanzdaten, Benutzerinhalte, Benutzerdaten und Diagnosedaten zuzugreifen. Während ich, wenn ich Push-Benachrichtigungen hätte und eine PWA nutzen würde, keine dieser Daten preisgeben würde.
Wir sehen also, dass ich trotz Apples Behauptungen eine PWA auf iOS nicht als gleichwertiges Erlebnis empfehlen kann, einfach wegen der Push-Benachrichtigungen. Aber es schadet nicht nur dem aktuellen Geschäft, es bremst auch zukünftige Geschäfte aus.
Ich habe nur wenige Argumente gehört, die Apples Entscheidung, nur Safari auf iOS zuzulassen, *verteidigen*. Vage Sentiments wie "Google kann nicht vertraut werden" machen den Großteil aus, datenschutzorientiert, leistungsorientiert oder beides. Alles in allem will niemand diesen vollständigen Mangel an Wahl außer Apple.
Soweit ich weiß, gibt es keine ganz klare Aussage von Apple, warum diese Anforderung besteht. Das wäre schön zu hören, denn vielleicht könnten dann die Gründe angegangen werden.
Wir hören ständig umwerfende Tech-Nachrichten. Ich würde gerne eines Morgens aufwachen und die Nachricht hören: "Apple erlaubt jetzt andere Browser-Engines auf iOS." Man wird ein leises *Jaaaaa* in der Luft hören, weil ich es so laut aus meinem Büro in Bend, Oregon, geschrien habe, dass man es bei Ihnen zu Hause hören kann.
Microsoft bündelt IE mit Windows und gerät in einen riesigen bundesweiten Prozess.
Apple beschränkt alle Browser auf die Nutzung ihrer Engine und das ist in Ordnung.
Ja, sie sind kein "Monopol", aber sagen wir, dass ein Unternehmen im Wert von ZWEI BILLIONEN DOLLAR keinen Einfluss auf De-facto-Standards hat?
Wenn ich mich recht erinnere, war einer der "Gründe" für die Nichtzulassung anderer Engines die Sicherheit: Indem der Schreibzugriff auf ausführbaren Speicher nicht erlaubt wird, wird die Sicherheit verbessert, also schützt Apple die Benutzer! (?)
Dann gibt es noch JIT-less V8, das entwickelt wurde, um das zu umgehen. Es umgeht nicht die Richtlinien von Apple, zeigt aber, dass es möglich ist, eine JavaScript-Engine außer Webkit laufen zu lassen, auch wenn Speicherbeschränkungen beibehalten werden, allerdings auf Kosten von *40% langsamerer Geschwindigkeit*.
Selbst wenn Apple die Webkit-Anforderung aufhebt, sind andere Engines immer noch im Nachteil, es sei denn, die Speicherbeschränkung wird aufgehoben… was unwahrscheinlich ist, da Apple argumentieren wird, dass es sich um ein wichtiges Sicherheitsmerkmal ihrer Betriebssysteme handelt.
Aber bleiben wir positiv, ich hoffe, jemand kann Apple dazu bringen, Safari separat von ihren Betriebssystemen aktualisieren zu lassen! Das war vor ein paar Jahren ein Problem auf Android und wurde behoben. Auch Apple kann nicht argumentieren, dass dies schlecht für die Sicherheit wäre. Es ist keine ideale Lösung, aber sie würde helfen.
Ich denke, es ist unerlässlich, dass andere Browseranbieter Browser mit JIT versenden dürfen. Dies würde eine Art Zertifizierungsprozess für Browser-Berechtigungen erfordern, aber es gibt viele Optionen. Der oben verlinkte Artikel von Alex Russell ist lesenswert, insbesondere https://deploy-preview-19–infrequently.netlify.app/2021/08/webkit-ios-deep-dive/#just-in-time-pretexts
Und gleichzeitig kritisiert Apple die EU dafür, die Innovation zu behindern, indem sie die Geräte zwingt, USB-C-Kabel zu verwenden, während sie auf ihren eigenen Geräten die Innovation so stark einschränken.
Ich schätze, Innovation ist nur dann gut, wenn sie von Apple Inc. kommt.
Ich würde gerne eines Morgens aufwachen und die Nachricht hören: "Apple erlaubt jetzt Push API & Notifications API"
Ich denke, zumindest historisch gesehen war die Akkulaufzeit ein Grund dafür. Wenn Sie Safari auf Ihrem Mac verwenden, werden Sie eine deutlich längere Akkulaufzeit feststellen als bei der Verwendung von Chrome, und bei mobilen Geräten ist die Akkulaufzeit oft wichtiger. Ich kann mir vorstellen, dass Apple nicht möchte, dass Leute ihnen eine schlechte Akkulaufzeit vorwerfen, wenn dies einfach daran liegt, dass Chrome ineffizient ist.