Webentwickler fordern die Erlaubnis alternativer Browser-Engines für iOS
von Felix Frank | 19 Kommentare
Es gibt doch verschiedene Browser im App Store für iOS-Geräte werden manche sicherlich sagen. Und grundsätzlich haben sie dabei recht, denn Apple verbietet es nicht einen eigenen Browser für das iPhone oder das iPad zu bringen. Bedingung des Ganzen ist allerdings die Basis WebKit, so schreibt es Apple in den Regularien für den App Store vor. Ob nun Chrome, Firefox oder Edge, hinter den Kulissen und einer alternativen Oberfläche steckt dann doch nur Safari. Damit hat letzten Endes doch wieder Apple die Rendering-Engine und damit die Zügel für Browser auf dem mobilen Betriebssystem in der Hand. Das stößt diversen Entwicklern – insbesondere Webentwicklern – oftmals sauer auf.
Die neu gegründete „Open Web Advocacy“ will Online-Apps helfen, mit nativen Apps zu konkurrieren. Erklärtes Ziel der Gruppe hinter den Entwicklern Stuart Langridge, Bruce Lawson und weiteren ist ein offeneres Web. Von der Gruppe werden deshalb Forderungen laut, entsprechende Beschränkungen für iOS-Browser zu lockern. Sie sind davon überzeugt, dass diese Politik dem Wettbewerb schadet. Hierbei verfolge man keine tiefergehenden Interessen, wie Profit, so der Zusammenschluss aus unabhängigen, einzelnen Entwicklern gegenüber The Register. Mit dem Vorhaben wandte man sich bereits an die britische Kartellbehörde, die hegte die Sorge, dass Safari zum „nächsten Internet Explorer“ wird. Hierbei spielt man auf Microsofts Update-Trägheit für jenen rund um die Jahrtausendwende. Ein Beispiel, welches auch vom deutschen Bundeskartellamt oftmals als Paradebeispiel für Auswirkungen bei fehlendem Wettbewerb und der Ausnutzung einer „Monopolstellung“ angeführt wird. Microsoft veröffentlichte damals nämlich über Jahre keinerlei Updates für den Internet Explorer.
Während sich die Kartellrechtsklage von Epic Games vorrangig auf das Zahlungssystem für den App Store fixiert, gäbe es bislang keine (rechtlichen) Ambitionen sich für alternative Web-Engines auf Apples Ökosystem einzusetzen. Apple wiederum stellt in diesem Zuge aber auch Web-Apps als „echten Konkurrenten“ für native Apps aus dem App Store dar. Aber auch jene sind durch die WebKit-Regeln eingeschränkt.
Das sieht auch die britische Kartellbehörde so. 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 wird in den kommenden Monaten erwartet.
Weiter noch mokiert man, dass Browser auf Basis von WebKit zudem nicht konkurrenzfähig seien, da Apple nicht vollumfänglich Zugang zu denselben APIs gewährt. Im Paper „Bringing Competition to Walled Gardens“ führt die Open Web Advocacy zudem weitere Punkte an, die alternative Web-Engines unter iOS ausmerzen könnten.
So ist nur Safari in der Lage Videos im Vollbildmodus zu zeigen, für alternative Browser erlaubt Apple dies nicht. Ähnliches gilt für Spiele im Vollbildmodus. Nur Safari erlaubt das „installieren“ von Web-Apps bzw. das Anlegen entsprechender Verknüpfungen auf dem Home-Bildschirm. Lediglich Safari sei in der Lage Browser-Erweiterungen, beispielsweise zum Blockieren von Werbung, zu verwenden. Außerdem sei auch die Apple-Pay-Integration in Browsern von Drittanbietern eingeschränkt. Zudem konsultiert iOS – auch bei der Wahl eines alternativen Browsers, die inzwischen bekanntlich möglich ist – bei In-App-Browsern Safari. Im Paper sind zudem weitere fehlende Funktionen und APIs gelistet. Darunter Push-Benachrichtigungen, etc. Zudem kritisiert die Entwickler-Gruppe die Update-Frequenz von Safari. Während Chrome alle vier Wochen neue Updates erhält, liefert Apple in der Regel solche Updates nur mit einem neuen iOS-Update aus.
Apple ist sich der benannten Kritik bewusst, hat aber bislang keine weiteren Schritte unternommen oder Stellungnahmen abgegeben.
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 ...
Naja der Grund ist einfach. Es gibt Engines die gehen akkuschonend vor und es gibt welche die das tun.
Der normale Nutzer weis aber nicht ob die Wahl seiner Browser dazu geführt hat das er plötzlich mit seinem iPhone keine 10 bildschirmzeit mehr hinbekommt oder das weil der Akku klein ist. Was auch nicht stimmt bei iPhones
Du kannst doch beim Energiemanagement nachschauen. Wer diesen Sachverhalt nicht versteht „App verbraucht viel Strom, d.h. ist der Akku schnell leer.“ nicht versteht ist wirklich dumm oder ich überschätze die üblichen iPhone-Kunden.
Finde ehrlich gesagt gut, dass da immer Apples WebKit dahintersteht. Wenn man jetzt andere Engines erlaubt, dann wird das am Ende eh ausschließlich Chromium und damit kann Google sein Quasi-Monopol nur noch mehr ausbauen und wahrscheinlich deutlich mehr Daten abgreifen, als sie es jetzt auf iPhones und iPads können.
Nur teilweise beabsichtigt, aber Webkit/Safari sorgt im Moment dafür, dass die Zahl der brauchbaren Apps unter iOS hoch ist und diese fast immer grauenhaften PWA eben nicht funktionieren. Und daher weht auch hier der Wind – „Safari ist der neue Internet Explorer“ ist vor allem das Mantra der Entwickler, die glauben, das es nur noch Webapps bedarf. Ressourcenschonend? Angepasste UI? Funktionalität des OS? Alles Dinge, die keine Rolle mehr spielen in dieser tollen Denkweise.
Da hast du leider einen Fehler in der Denkweise.
Für PWAs (und auch für hybride Apps) nutzt Apple nochmal eine abgespeckte WebView (WKWebView bzw. SFSafariViewController), welche viele Funktionen komplett gar nicht implementiert. WebRTC wäre da z.B. ein sehr prominentes Beispiel, was nur im Safari aber nicht in WKWebView funktioniert (und im Safari auch erst korrekt seit 1-2 Jahren).
Angepasste UI, Funktionalität des OS, usw. sind auch alle mit WebApps möglich. Allerdings eben nicht vollständig bei iOS, da dort eben seit Jahren von Apple mit Blockwart-Mentalität gegen vorgegangen wird.
Noch dazu kommt, dass WebKit die schlechste CSS3/JS Kompatibilität aller BrowserEngines besitzt und somit quasi jeder WebEntwickler auch für normale Webseiten immer 100 extra-würste für Safari einbauen muss. Im übrigen oft sogar JavaScript verwenden muss, um Features die eigentlich CSS-Standard sind, umzusetzen. Was natürlich auch zeitgleich wieder an der Performance zieht 😉
Naja, ich bestreite halt , dass das von dir postulierte „…sind auch alle mit WebApps möglich“ so hinhaut, selbst unter optimalsten Bedingungen sind Webapps den nativen Apps unterlegen. Ich warte immer noch auf eine Webapp, die bei zumindest annähernd gleicher Funktion nicht ein völliger Ressourcenfresser wäre (von der Integration ganz zu schweigen) – muss gar nicht iOS sein, ist imho überall so.
Es kommt drauf an wie du WebApps definierst. Wenn du von reinen PWAs sprichst, ja, dann bist du eingeschränkter, eben auf DAS was dir die WebView überhaupt freigibt… und das ist unter iOS z.B. schon mal nicht viel. Aber mal ganz ehrlich, was für OS-Funktionen nutzt man denn typischerweise. GPS, Bluetooth (nur Android), Kamera, scannen von QR Codes (nur Android… ), Mikrofon, Teilen Menüs, Clipboard, Telefon-App öffnen, E-Mail Client öffnen, Zugriff auf Galerie und Dokumente, etc. kannst du alles selbst mit ner PWA nutzen. Unterschiedliche Designs (Material-Design,, Light und Dark-Mode (sogar OS gesteuert) ebenfalls. Selbst Pushbenachrichtigungen sind auf dem Weg. Alles komplett im Browser bzw. der WebView.
Ich kann dir theoretisch sogar einen Chat inkl. Videokonferenz, Bild- und Sprachnachrichten, etc. rein als PWA schreiben. Würde halt nur nicht unter iOS laufen mangels WebRTC support für die WebView. Ja, ein solcher Chat könnte nicht auf die Kontakte zugreifen, das wäre z.B. eine (nützliche) Limitierung bei der eine native App einen Vorteil hat… allerdings ist das datenschutztechnisch sowieso nicht erlaubt, ohne dass all deine Kontakte dem zugestimmt haben, von daher aus der Sicht vielleicht sogar ganz gut so.
Zudem gibt es auch noch jede Menge Hybrid-Apps im AppStore, also solche die eigentlich eine WebApp sind und über eine native App eigentlich nur eine WebView ausliefern, welche die WebApp (üblicherweise aus der App heraus, nicht übers Internet) ausspielen. Da kann ich dir garantieren, dass du gar keinen Unterschied zu einer komplett nativen App merkst. Ich würde sogar soweit gehen, dass eine mehr als 50% Chance besteht, dass du eine solche App nutzt ohne es zu merken. Dafür sorgen nämlich die vielen Frameworks, die sich komplett für dich um die Design-Elemente kümmern via WebComponents und die alles, was du nicht über die WebView machen kannst, einfach als native Plugins mittels Bridge in der WebApp bereitstellen.
„Ja, ein solcher Chat könnte nicht auf die Kontakte zugreifen“
https://web.dev/contact-picker/
🙂
Ganz früher gab es 2 Browser Engines unter iOS. Die uralte von Apple, welche Fremd-Browser nutzen mussten und WebKit. Bei einer Google Chrome Version konnte man warum auch immer zwischen beiden wechseln. Mit dem nächsten Update ging das nicht mehr. Mittlerweile nutzen alle WebKit.
Nur meine Frage: Ist das so nicht weiterhin möglich? WebKit, Chromium und Gecko zwingend zur Auswahl für jeden Browser und der erfahrene Nutzer wählt selber? Oder war das damals mit der alten Apple Browser Engine was anderes und deswegen einfacher umzusetzen?
Und ich habe nichts gegen Safari. Ihn als neuen Internet Explorer zu bezeichnen finde ich falsch.
> Und ich habe nichts gegen Safari. Ihn als neuen Internet Explorer
> zu bezeichnen finde ich falsch.
Du bist Anwender.
Ich arbeite in der Qualitätssicherung von Websites. Ich könnte mir den Satz „Problem nur unter iOS“ auf eine Funktionstaste legen, so oft muss ich den tippen.
Das Du davon nichts merkst, liegt daran, dass wir einen erheblichen Mehraufwand da reinstecken. Müssen.
Ich bin seit 16 Jahren Webentwickler und ganz ehrlich, das ist absoluter Unsinn. Die Kleinigkeiten, welche bei Safari anders laufen haben auch in Grenzen und lassen sich im Normalfall mit etwas Berufserfahrung im vornherein vermeiden. Wir haben in der Firma einmal einen Safari Learning Day gemacht und seitdem gibt es diesbezüglich keine Probleme mehr. Und eben auch keine zusätzliche Zeit, die dafür aufgewendet wird, weil man schlichtweg weiß, was man tun muss bzw. dann Babel, ESLint und Co. noch nicht mal drüber nachdenken muss.
Das ist weit entfernt von „erheblichen Mehraufwand“ und hat absolut gar nichts mit der katastrophalen Situation von damals mit dem Internet Explorer zu tun. Da ist selbst Firefox mit seinen Befindlichkeiten oft noch schlimmer. Aber zum Glück in vielen Kreisen mittlerweile auch irrelevant.
> Ich bin seit 16 Jahren Webentwickler und ganz ehrlich,
> das ist absoluter Unsinn.
Und ich seit 22 Jahren, und es ist kein Unsinn. Und nun?
Ich weiss ja nicht, was Du machst. Meine Projekte sind Großkunden mit Auftragsvolumina über 1 Mio. Ich kann natürlich keine Namen nennen, aber stell dir solche Sachen vor wie der Webshop von H&M, Rolex oder der Ersatzteilshop von Opel (Alles NICHT meine Kunden, aber vergleichbare Wettbewerber der genannten)
Diese Unternehmen haben nicht bloß hippe iPhone-15-Endkunden. Eine Unterstützung von IE11 oder iOS 12 ist hier noch selbstverständlich, weil die Firmen in ihre Analytics gucken, was sie das kostet, den abzusägen — und es lohnt sich nicht.
Es lohnt sich sogar, Testerteams mit einer dreistelligen Anzahl diverser Handys auf die Webapplikation loszulassen und sich das auch mal mit Android 6 anzugucken, oder iOS 12 (Automatisiertes Testing gibt es ZUSÄTZLICH, das sind nur die Smoke Tests)
Klar, wer seine Frameworks immer auf Versionsnummer „*“ requiren kann, der hat natürlich weniger Probleme mit „Safari latest“ für iOS… Ich kenne keinen FE-ler bei uns, der den Browser nicht hasst. Und auch wenn ich nicht mehr selber code, ich weiss, dass wir gute Leute haben, und für welche Browser wir Bugs schreiben. Es ist immer wieder die Scheiss Safari Sonderlocke.
Es gibt doch am Browsermarkt keine Vielfalt mehr. Alles Chromium. WebKit wird quasi nur noch von Apple genutzt und bei Gecko weiß man doch auch nicht, wie lang sich Mozilla noch halten kann.
Dunno. Ich sehe nicht, wo ich aufgrund der Engine eingeschränkt bin.
Der Kommentar macht so irgendwie keinen Sinn. Du sagst, Chromium ist extrem weit verbreitet — dann heisst das ja erst recht, dass einem das am weitesten verbreitete Produkt vorenthalten wird und man auf eine Randgruppenengine 🙂 gezwungen wird.
Zweitens heist „Chromium“ nicht: „Das ist der Chrome mit einem anderen Menü drüber“. Chromium-basierte Browser bieten eine ERHEBLICHEN Mehrwert: Kiwi kann die normalen AddOns nutzen, Brave unterstützt Privacy, Vivaldi kann mit meinem Desktop-Vivaldi sync’en, und last but not least trifft jeder dieser Browser andere Designentscheidungen — zum Beispiel kann ich in Kiwi diesen ganzen Tabgruppen-Krempel deaktivieren, der für mich störender Mega-Overhead ist.
Entscheide doch bitte nicht für die anderen. Wenn Du Safari willst — nutze ihn, gut.
Das können all die Browser auch weiterhin – auch ohne entsprechende Render-Engine. Ich sehe dazu absolut keinen Mehrwert und ich sehe auch nicht, wo eine Webseite auf dem iPhone „unbedienbar“ wird. Das klingt eher nach Faulheit von Webentwicklern. Das verschiedene Engines verschiedene Tweaks im Code benötigen ist keine Neuheit und wird es erst dann nicht mehr geben, wenn wir gar keine Wahl mehr haben.
Blink, also der HTML-Renderer von Chromium, ist btw. auch nur ein WebKit-Fork…
WebKit wird nebenbei bemerkt auch von Steam genutzt – oder bspw. von einigen Browsern, die eher auf Linux zuhause sind…
Kurz: Für den Ottonormal ist es absolut Rille, ob Chrome, Edge, Opera, Firefox und Co. auf einem iOS-Gerät mit WebKit laufen oder mit Blink/Chromium… Die von dir beschriebenen Funktionen sind davon vollkommen unabhängig.
Nein. Siehe dazu z.B. die APIs, die Google grad streicht und die Adblockern das Leben erschweren. Die Browserengine ist weit davon entfernt, „egal“ zu sein.
Ich finde es gut, wenn Software nur unter MS-DOS läuft. Wenn man jetzt einen Farbmonitor anschliesst oder die Hercules-Grafikkarte nicht läuft, weil die Nutzer da IBM-DOS oder sogar Windows installiert haben, dann heisst es nur wieder „Microsoft ist schuld!“. Es hat ja nicht jeder Informatik studiert.
Ich habe auch ehrlich gesagt keine Lust, mich mit irgendwelchen anderen Office-Paketen rumzuärgern. Word 2.0 funktioniert super, und wenn man das in Lotus oder edlin aufmachen will, gehen nur Sachen kaputt. Warum sollte Microsoft das supporten? Ihre Plattform, ihre Regeln. Jeder, dem das nicht passt, kann sich einen C64 oder den Zuse1 hinstellen und machen, was er will.
Stellt euch mal vor, jeder könnte einfach mal Software entwicklen! Da würde doch nichts mehr laufen! Das erste Programm nimmt sich die ganzen 640KB, und die anderen haben den Supportaufwand.
Ehrlich gesagt, ziemlich asozial. Gut, dass Microsoft da den Daumen drauf hat.
Warum es einen Wettbewerb und Engines geben muss, wenn Features On Top in der App umgesetzt werden (Bsp: https://support.google.com/chrome/answer/165139?hl=de&co=GENIE.Platform%3DiOS) oder wenn Hersteller um Parität bemüht sind (Bsp: https://wpt.fyi/interop-2022), muss auch mal einer erklären.
Und dann verabschiedet sich Google ja noch vom Ad Cookie. Das müssen brauchbare Alternativen her, die Apple nicht blockt (Bsp: https://www.zdnet.com/article/apple-declined-to-implement-16-web-apis-in-safari-due-to-privacy-concerns/)
Verstehe ich sowieso nicht .. Microsoft hat von der EU schon so oft (u.a.) wegen ihrem IE auf den Sack gekriegt .. Warum gilt das nicht für alle Hersteller?