Google und Mozilla könnten sich auf iOS-Browser mit eigenen Engines vorbereiten
von caschy | 16 Kommentare
Nicht wirklich ein steiles Gerücht, doch man kann sicherlich mal darüber berichten. Apple wird ja seit langem vorgeworfen, dass man einen „goldenen Käfig“ betreibe. Das gilt nicht nur für den App Store, den andere Betreiber um Alternativen erweitert sehen wollen, sondern auch für die Browser.
Da gibt es zwar zahlreiche für iPhone und iPad, doch sie alle setzen nicht auf ihre normalen Engines, es ist immer WebKit-Rendering. Dies schränkt die Anzahl der neuen Funktionen ein, die von konkurrierenden Browsern angeboten werden können, und bedeutet vielleicht auch, dass es unmöglich ist, einen iPhone-Browser zu entwickeln, der Seiten schneller als Safari rendert.
Von daher ist es nicht verwunderlich, dass es da Webentwickler und auch andere Unternehmen gibt, die dahingehend Freiheit für andere Engines von Apple fordern. Die britische Kartellbehörde hatte bereits letztes Jahr ein Auge drauf. Man äußerte sich wie folgt: „Wir haben festgestellt, dass Apple die Qualität und Funktionalität aller Browser auf iOS-Geräten kontrolliert und einschränkt, indem es von allen Browsern auf iOS-Geräten verlangt, seine WebKit-Browser-Engine zu verwenden. Dies schränkt auch das Potenzial für konkurrierende Browser ein, sich von Safari zu unterscheiden“. Eine konkrete Entscheidung und mögliche Weisung gegenüber Apple ist da vermutlich nicht aus dem Raum.
Browser-Hersteller scheinen sich auf den Schlag gegen Apple vorzubereiten, wobei die meisten Browser halt doch nur auf die Code-Basis von Chromium setzen, darunter Microsoft Edge, Opera, Vivaldi und Brave. Da setzt man auf die Rendering-Engine Blink, eine Abspaltung von WebKit. Anders Firefox, die setzen auf Gecko. Sowohl bei Google als auch bei Mozilla wurden wohl nun Codes erspäht, die darauf hindeuten, dass Entwickler auf den Tag hinarbeiten, ab dem Apple andere Engines erlauben muss. In einigen Medien werden die jeweiligen Projekte als Browser-Tatsachen verkauft, erwähnen sollte man, dass zumindest das Blink-Team erwähnt, dass es sich um eine experimentelle Version zum Testen von Eingabe-Latenzen handelt.
Ein Google-Sprecher gab eine ähnliche Antwort. »Dies ist ein experimenteller Prototyp, den wir als Teil eines Open-Source-Projekts entwickeln, mit dem Ziel, bestimmte Aspekte der Leistung auf iOS zu verstehen«, so ein Sprecher gegenüber The Register. »Er wird den Nutzern nicht zur Verfügung stehen und wir werden uns weiterhin an die Richtlinien von Apple halten.« Erzählen kann an ja bekanntlich viel.
Mal schauen, was das dann gibt. Konkurrenz belebt das Geschäft, nur die Sicherheit darf eben nicht auf der Strecke bleiben.
Transparenz: In diesem Artikel sind Partnerlinks enthalten. Durch einen Klick darauf gelangt ihr direkt zum Anbieter. Solltet ihr euch dort für einen Kauf entscheiden, erhalten wir eine kleine Provision. Für euch ändert sich am Preis nichts. Partnerlinks haben keinerlei Einfluss auf unsere Berichterstattung.
Wird geladen ...
Dann bekommt iOS nach all den Jahren endlich mal einen richtigen browser, sollten die Restriktionen irgendwann mal von der EU aufgehoben werden! 😀
Würde ich in jedem Fall begrüßen, da für mich Safari der schlechteste der großen Browser ist.
Der schlechteste ist ja wohl eindeutig Chrome. Unterstützt als einziger nicht einmal Adblocker.
Kommt drauf an was man möchte.
Ich persönlich würde gerne öfter eine PWA nutzen – vor dem AppStore hat btw. Apple extra genau dafür geworben und das als Grund genommen damals zu verteidigen dass es keine native Software von Drittanbietern gibt.
Leider kann Safari bzw. auch die Engine deutlich weniger als andere Browser sodass PWA bei iOS auch entsprechend deutlich weniger können. Wäre das der Fall würde man wohl in vielen Fällen auch auf eine App (und damit auf die knapp 100 €/Jahr für den Dev-Zugang) im AppStore verzichten können.
Adblocker sind mir persönlich recht egal. Ads blocke ich direkt auf Systemebene.
Aber der Grund, warum PWAs besser sind als Apps ist doch, weil man dort vernünftig adblocken kann, oder? Warum sonst nicht nativ?
Nein, PWAs sind nicht zwangsweise „besser“. Für viele Dinge reicht aber eine PWA.
Z.B. für Fahrpläne, Webradios, manche Spiele. Wenn man sich anschaut wie viele Apps eigentlich nur HTML/JS sind mit einem Wrapper wie z.B. Dordova ist oft auch eine Portierung relativ einfach.
Für den Entwickler spart es halt reines Geld (keine jährliche Gebühr für den App Store) und man muss auch nicht auf die Launen von Apple angewiesen.
Beides ist natürlich für Apple eben nicht besonders erstrebenswert. Ist wahrscheinlich einer der Gründe warum Apple diverse Standards die einer PWA nativere Dinge erlaubt nicht umsetzt.
Ich hab nicht geschrieben PWAs seien zwangsweise besser. … ich hab geschrieben der Grund für PWAs sei Contentblocking.
Dass es die Kontrolle durch die Stores reduziert ist m.M.n. aber ein fairer zweiter Grund, da geh ich mit.^^
Der schlechteste in jeder Hinsicht ist offensichtlich Safari. Große Teile der Standards des Webs werden nicht unterstützt, einzig um die absolute Kontrolle um jeden Preis zu haben. Sobald alternative Engines zugelassen werden, kann man nur hoffen, dass Webseiten keinerlei Anstrengungen mehr unternehmen werden, damit der Müll die Seite auch nutzen kann. ist, als würde man den Internet Explorer unterstützen. Dann bliebe Apple wenigstens nichts anderes möglich, als endlich die Entwicklung von Safari voranzutreiben, um eine echte Konkurrenz darzustellen oder den Müll einzustampfen.
> Sowohl bei Google als auch bei Mozilla wurden wohl nun Codes erspäht
Was Mozilla betrifft, ist das erstens seit Oktober 2022 bekannt. Nur The Register hat das erst jetzt gefunden. Zweitens: Nein, „Code“ wurde dort überhaupt keiner „erspäht“, weil die Arbeit in einem privaten Repository stattfindet. Lediglich ein GitHub-Issue dazu ist öffentlich. Aber kein Code.
Hoffentlich bekommen wir bald Konkurrenz auf IOS. Auf dem MacBook benutze ich Brave, ich verschwende keinen Gedanken an Safari mehr. Unter IOS ist Brave leider nur ein Safari Klone.
Kein Klon, ein Wrapper, das ist viel schlimmer. Ein Klon könnte Dinge anders machen, das ist unter iOS ausgeschlossen.
Was stört euch an Safari auf dem iPhone?
Kein kosmetisches content blocking und nur sehr begrenztes netzwerkblocking.
Was am meisten stört ist die Rückständigkeit beim Bezug auf unterstützte Web Standards. Bilder mit WebP effizienter codiert auszuliefern als mit JPEG ist gerade so seit nem Jahr möglich, alle anderen Browser unterstützen das bedeutend länger. Daher muss man also nicht Mal Apple Nutzer sein, als Webseitenbetreiber muss man aufgrund solch unnötiger Kleinkrige Fallbacks definieren und realisieren. Da Apple Konkurrenz unmöglich macht, sind sie aber auch nicht gezwungen, besser zu werden.
Konkurrenz? Google hat doch sowieso totale Dominanz mit Chrome (Blink), AMP und Google-Diensten und Microsoft Edge.
Ich kann mich als Anwender nicht über Fehler mit Safari beschweren. Aber Webentwicklern jammern zu gerne, wenn andere Browser nicht so rendern wie „ihr“ Webbrowser. Und die Nummer hatten wir 2001 schon mal mit Microsofts Trident (die Engine des IE). Das W3C ist sowieso ein Witz. Es wird gemacht was Google will.
Was Apple macht ist natürlich Mist. Und da hätte vor zehn Jahren durchgegriffen werden müssen. Aber es sollte nicht darum gehen Google noch mehr Dominanz zu verschaffen. Google terrorisiert einem ja bei jedem Aufruf unter iOS mit “Möchten sie nicht einen Account?”. Viel mehr sollte man die Installation von eigenen Apps wie unter Android verpflichtend ermöglichen. Was Apple in seinem AppStore macht, ist Apple dann überlassen.
Umgekehrt sollte man mal Google komplett mit Auflagen wie bei AT&T belegen. Kein Markteintritt in ein neues Segment! Und Android soll endlich mal IMAP-Push, CalDAV und CardDAV können. Die ganze Standards [sic!] kann Android nicht. Push funktioniert nur mit Gmail. Apple hat die alle ordentlich umgesetzt. Viel wichtig ist in der Praxis leider, was vorinstalliert ist. Damit wir die Nutzemasse gesteuert und Macht ausgeübt.
Kurzum:
Wie brauchen dringend mehr Förderung für Gecko und WebKit. Letztes nutzt dann auch Epiphany unter Linux. Apple arbeitet da tatsächlich mit anderen mit und WebKit wird deswegen gern als Basis genutzt.
Es geht nicht mal großartig ums Rendern, es geht darum dass Apple in Safari ganze APIs nicht implementiert.
Beispiel: WebPush. Ist erst letztes Jahr auf macOS gekommen. In iOS immer noch nicht drin, auch wenn es nach all den Jahren zumindest endlich mal angekündigt ist.
IMAP-Push ist in der Tat ärgerlich. Gibt zwar andere Mailclients, aber die sind nicht unbedingt besonders praktisch.
Das CalDAV, WebDav und CardDav nicht nativ in Android drin ist juckt mich eher weniger. In Android lässt sich das nahtlos durch kostenfreie Apps wie DAVx5 nachrüsten. Termine laufen dann in den Kalenderspeicher die sich von jeder enstprechenden App mit Zugriff Zugang hat. Analog bei Kontakten.
Mir wäre neu dass Apple IMAP Push/IMAP Idle kann. Afair nur bei iCloud. Und natürlich Exchange ActiveSync. Das hat kaum was mit offenen Standards zu tun.
WebDAV hat Apple übrigens selbst auch nicht.
IMHO ist die Blink-Engine auch so groß geworden weil Electron Entwicklern halt schon viel Arbeit abnimmt z.B. um auch rein lokale Software anbieten zu können ohne große Anpassungen zur bestehenden PWA zu machen.
Mozilla hatte sowas auch mal. Wurde aber eingestellt und wieder ein neuer Versuch gewagt. Und wieder eingestellt. Das ging 3 oder 4 mal so.
Verständlich dass keiner dann mehr die Gecko-Engine für solche Zwecke nutzen will, muss man doch davon ausgehen dass Mozilla einen neuen Versuch dazu auch wieder einstellt.