Apple keurt Edge, Firefox en DuckDuckGo goed als standaardbrowser in iOS 14

Apple heeft Microsoft Edge, Firefox en DuckDuckGo goedgekeurd voor gebruik als standaardbrowser in iOS 14. Apple had Google Chrome al eerder goedgekeurd. Door de goedkeuring kunnen gebruikers de browsers in iOS 14 als standaardbrowser instellen.

Edge, Firefox en DuckDuckGo Privacy Browser proberen zich te onderscheiden met privacyfuncties, meldt 9to5Mac. Chrome biedt vooral het synchroniseren van gegevens met de desktopversie als onderscheidende functie, een functie die Firefox overigens ook heeft.

Apple laat nog altijd niet toe dat browsers een andere rendering-engine gebruiken dan Webkit op iOS. Daardoor zijn de alternatieve browsers herverpakte versies van Safari met toegevoegde functies. Het is onbekend of er nog meer browserbouwers zijn die als standaardbrowser in aanmerking willen komen.

Behalve een andere standaardbrowser kunnen gebruikers onder iOS 14 ook een andere mailclient als standaard instellen. Apple bracht iOS 14 woensdagavond Nederlandse tijd uit. Tweakers publiceerde in juni vlak na de presentatie al een preview van iOS 14.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (164)

De laatste versie van Outlook mobile staat ook toe dat deze als default mail app in te stellen is! Versie 4.55.1.

Ik heb de testflightversie 4.56 van Outlook en daar kan ik het nog niet in vinden

Instellingen, Outlook en dan Standaard Mail-app.

Vanmorgen kwam er een update van de testflightversie en nu heb ik hem ook, maar kan makkelijk zijn dat ik gewoon niet goed gekeken heb Nu Gmail nog!

Dat, maar het zit ook gewoon in de niet Testflight versie van deze week :-) . Draai op iPhone gewoon de normale versie en op m'n iPad de Testflight. Hoe dan ook... Wat een genot!

Outlook is imo de beste Gmail client op IOS

Apple heeft vandaag de Microsoft Edge app trouwens ook goedgekeurd als standaardbrowser in iOS 14

Dat staat toch ook in het artikel?

Het artikel is aangepast, eerst stond het nog niet in het artikel

Klopt, het artikel is aangepast aan de snelheid van de browser, vandaar dat edge wat later was...

Vandaar dat er ook nog beide staat?

Staat toch ook in het artikel? Edge, FF en DuckDuckGo zijn nu als default bruikbaar naast Safari en Chrome.

Stond er nog niet in.

Damn ninjas.

Er is zelfs nog een hint achtergebleven in de tekst: "Edge, Standaardbrowser instellen in iOS 14Firefox en DuckDuckGo Privacy Browser proberen zich beide te onderscheiden met privacyfuncties,"

Nog een hint in de inleiding(?) "Door de goedkeuring kunnen gebruikers de drie browsers in iOS 14 als standaardbrowser instellen.". Het zijn er dus 4 .

Tijd voor een fatsoenlijke changelog/versie

Ja dat maakt het wat makkelijker te zien. Het is een beetje annoying, want nu is deze hele thread kompleet nutteloos, maar hangt wel onder een +2. Niet handig.

Apple laat nog altijd niet toe dat browsers een andere rendering engine gebruiken dan Webkit op iOS. Daardoor zijn de alternatieve browsers herverpakte versies van Safari met toegevoegde functies.

Dit blijft gewoon eeuwig zonde Zeker ook omdat WebKit vaak een beetje achterloopt op de echte Safari app qua optimalisaties.

Het is juist zo prettig om meerdere browser engines te hebben voor het geval iets niet goed rendert op een bepaalde website. En zo kan ook elke browser echt volledig functioneren, zoals Firefox met zijn plugins die op Android beschikbaar zijn (volledige uBlock Origin bijvoorbeeld!)

Dit vind ik echt iets dat gewoon mogelijk moet zijn als de gebruiker daar voor kiest.

[Reactie gewijzigd door GekkePrutser op 17 september 2020 15:44]

>Het is juist zo prettig om meerdere browser engines te hebben voor het geval iets niet goed rendert op een bepaalde website.

Aan de ene kant is het handig om een andere browser te hebben als er een niet werkt, aan de andere kant krijgen webdevs hoofdpijn van het aantal verschillende browsers met verschillende standaarden die ze moeten supporten.

Webdevs moeten standaarden ondersteunen, geen specifieke browsers.

Browsers moeten standaarden ondersteunen maar dat boeit browsers niet. Dus webdevs moeten browsers ondersteunen.

Ik stelde het express even zwart-wit.
Maar feit blijft wel dat als men steeds maar weer zich richt op browsers ipv standaarden, de browsers nooit standaarden goed zullen ondersteunen.

Aan de ene kant heb je gelijk maar sinds Apple een dicatatoriale greep heeft over hun ecosysteem valt er weinig te doen behalve hopen dat hun dev team met het goede beentje uit bed stapt.

Alsof webdevs zich niet al jaren voor Apple een significante factor werd op browsers richtten...

Dit is al sinds de jaren 90 een probleem en het zal zich blijven voordoen zolang men zich niet richt op standaarden. Het probleem is echter eigenlijk alleen maar erger geworden. Ooit was er een tijd dat er vrijwel niets verdiend werd met internet, nu spreekt het geld ook mee en wordt het dus veel lastiger om een groep gebruikers uit te sluiten omdat die een browser gebruiken die zich niet aan de standaarden houdt.

Sowieso is er niet een browser die zich aan alle standaard houdt.

> Het probleem is echter eigenlijk alleen maar erger geworden.

HOLD MY BEER!

Het probleem was dat je 2 code paden voor elke functie in JS had voor netscape en internet explorer en dat je conditional comments gebruikte om de rare box model bug (waar we box-sizing: border-box aan over hebben gehouden) te fixen in Internet Explorer (tot en met 8 uit mijn hoofd).

Tegenwoordig kan ik, en daarmee anderen ook prima een website schrijven die geen of minimale aandacht nodig heeft na browserchecken.

> Sowieso is er niet een browser die zich aan alle standaard houdt.

Zojuist even Chrome, Firefox en Safari door de acid3 test (http://acid3.acidtests.org) gehaald, zegt niet alles maar toch.

Safari: 98/100
Chrome: 97/100
Firefox: 97/100

Uitslag verbaasde mij wel eerlijk gezegd.

[Reactie gewijzigd door Ed Vertijsment op 17 september 2020 17:27]

Ik had ze al door de test heengehaald voordat ik de opmerking plaatste

Technisch is het inderdaad niet lastiger geworden. Het punt is van niet-technische aard.
Leuke reactie, back to memory lane

Haha en dan die LAYER tags in Netscape 4, SPACER.GIF in iedere lege cel, regels rondom waar je je newline neer kon zetten, VBScript en god weet wat ik nog meer vergeten ben.

Tabellen

Interessant, met Pale Moon haal ik 99/100

Ik wil Firefox niet afvallen maar Firefox op iOS draait natuurlijk gewoon WebKit (safari) in verband met Apple's policy (ik zou graag zien dat iOS andere engines toeliet). Dat die 98 haalt is dan ook niet vreemd, gelijk aan Safari .

De rest van je verhaal heeft met Apple's app store te maken en een website, vervelend dat je een bug (wellicht) tegenkwam maar dat heet niets met Safari te maken. Je laatste opmerking is dan ook nogal overtrokken. Er zijn zo veel "stukke" links.

[Reactie gewijzigd door Ed Vertijsment op 17 september 2020 20:13]

Zeker, ik weet dat het WebKit all what the clock beats is.
Maar als we Firefox 98 ipv 97 willen laten scoren op iOS sleuren we er graag Firefox Focus bij.

Ik heb écht niet moeten gaan graven om een error te vinden in de "mobile experience"

Er zijn zoveel Stukke links? --> mogelijk voor U maar ik uit met die overtrokken commentaar verbazing dat het een eerstelijns weblink , dwz vertrekkende van Apple's standaard programma ("native app der apps, de appstore")naar Webbrowser (Safari) niét blijkt te werken en het tot overmaat nog een onduidelijke boodschap weergeeft: gebruik laatste versie van Safari, Firefox: wél die héb ik.

Dus mijn commentaar ware overtrokken mocht hier een bedrijf van 25 mankracht achter zitten programmeren maar dat Apple niét.
Geef me een dagje en ik lijst U netjes alle eerselijns links vanuit standaard "apps" van Apple op iOS en of ze werken of niet. En of het Mobile of Desktop browsers betreft.
En dat goedkoper dan de gemiddelde codeschrijver/tester in Apple's loondienst zal leveren.

[Reactie gewijzigd door Vetsmelter op 18 september 2020 10:52]

maar dat heet niets met Safari te maken.

internet explorer was een ramp! ik kan me nog een tijd herinneren dat je na het ontwikkelen van een website, nog een aardig tijdje bezig was om allemaal ie6 / ie7 hacks en uitzondering te doen (kennen jullie PIE nog??) verschrikkelijk, bij mij ging echt de vlag uit toen IE zn monopolie verloor en nog een keertje dubbel toen IE definitief begraven werd. Wat heb ik daar op gescholden zeg vroeger. Vieze DX transform hacks, gifjes moeten gebruiken voor shading

Dit dus, ik heb echt niets te klagen over de huidige stand van de standaarden. Dat je, je een beetje moet verdiepen in wat is doorgevoerd en production ready is, is van alle tijden.

idd... tegenwoordig is het altijd wel globaal aan te passen zodat het in alle browsers werkt. die gore IE versie specifieke extra css includes zijn gelukkig echt verleden tijd

Webdevs moeten standaarden ondersteunen, geen specifieke browsers.

Dat is in de ontwikkelfase wellicht waar, maar hoe test je dat? Met een browser die die standaard implementeert.

[Reactie gewijzigd door 84hannes op 17 september 2020 18:21]

Zeg maar tegen de klanten van de webdevs dat hun browser de standaarden niet ondersteund...

Zo werkt dat helaas niet. Brouwers zouden standaarden moeten ondersteunen. Als dat niet het geval is moeten devs voor browsers developen.

99,9999999999% van de tijd krijg ik toch echt hoofdpijn van Safari/Webkit

Dan doe je volgens mij toch echt iets niet goed? De projecten waar ik aan werk zijn gewoon standards based en werken doorgaans in pretty much alles bij de 1e testsessie, inclusief IE11 en Safari. Kan je een voorbeeld geven van iets waar je dan hoofdpijn van krijgt?

Heb hetzelfde als DarkBlaze hoor.

Vrijwel de enige browser-specifieke workarounds die ik nog schrijf, zijn voor dat gedrocht genaamd mobiele Safari

ik weet er een workaround zo uit mijn hoofd te noemen. De variable hoogte van de werkbalk aan de onderkant waar je nog wel eens rekening mee moet houden. Kun je er een paar nomen (oprechte interesse)?

En het ergste is nog dat Apple hun dev tools gewoon bagger zijn. Net als dat ze soms compleet verdwijnen uit de simulators en je dus ineens niet kunt debuggen, tenzij je een hele batterij aan devices aanschaft.

De tooling van Apple is redelijk mits je weet hoe je ze moet gebruiken, dat is voor mij altijd weer een puzzel dus pak ik Chrome als default.

Offtopic, maar hetzelfde als dat je airpods enkel kan updaten met een iPhone?

Het is wel des Apples dat je enkel met hun software/hardware kan werken als je die hardware ook zelf hebt en op werkt

Nee, ik doe niets verkeerd hoor, is toch echt apple die afwijkt met bepaalde zaken in hybride apps bijvoorbeeld.

Probeer maar eens een pwa te maken met push notifications bijvoorbeeld. Wordt gewoon niet ondersteund.

Ook onze three.js implementatie heeft iOS/Safari specifieke fixes.

[Reactie gewijzigd door DarkBlaze op 17 september 2020 20:19]

Push notification worden inderdaad niet ondersteund. Je fixes voor three.js ben ik wel benieuwd naar. Heb je specifieke code die op browser A iets anders doet dan browser B?

Ja, heeft met touch events te maken, is niet mijn code maar ik integreer het wel in de mobile app en loop er dus wel tegen aan.

Oe misschien dat iOS meerdere touches per events registreerde?

Afaik is dat namelijk een api die herzien is ivm multitouch en nu ook zo op Android werkt.

Nou ik heb er weer een voor je

Safari 14 geeft als language nu nl-nl ipv nl-NL terug en opeens was de app in het Engels

Trust me, web devvers krijgen vooral hoofdpijn van monopolistische browsers.
Denk aan IE (vroeger), of chrome (nu), en Safari (op ios)

Liever gewoon allerlei browsers die het redelijk tot goed doen, dan 1 browser die na verloop van tijd nooit meer nieuwe features krijgt maar wel de markt beheerst.

Vroeger toen je nog IE 6 moest ondersteunen en IE8 top of line was...

Als je nu nog regelmatig browser specifieke issues heb, doe je het niet goed. Dan houdt je geen rekening met wat het meerendeel van de browsers ondersteunt.

Inderdaad, daarom draai ik ook Firefox, Firefox beta en Firefox Focus

Maar dat moeten ze toch al op andere OS'en? Dus iOS erbij maakt niet zo veel uit als iOS andere engines zou toelaten.

Probleem is niet zo zeer dat er meerdere standaarden zijn maar dat bepaalde browers de geldende standaard niet volgen. De oude versies van IE waren hierom berucht.

Ik weet dat Firefox op dit gebied aardig scoort, chrome dacht ik ook wel.

Als browsers hun eigen render engine mochten gebruiken in ios en meer websites zouden werken zoals in desktop versies van de browsers zou de noodzaak voor héél apps wegvallen, geen app, geen geld voor Apple.

Dat is gewoon onzin gezien het feit dat er webapps te over zijn en Safari op iOS dit ook actief ondersteund. Je kunt een website namelijk gewoon als een app icoontje op het beginscherm neerzetten. Tik je daar dan op dan opent in sommige gevallen niet de website maar een webapp versie. Instagram is daar een voorbeeld van. Dat rijmt totaal niet met jouw theorie.

De reden waarom Apple zo moeilijk doet over die render engine is waarom ze ook zo moeilijk doen met bepaalde frameworks en het downloaden van code. Ze vinden dat niet secure. Is overigens niet geheel ongelogen. Als we echter kritisch kijken dan kun je hier wel vragen bij zetten, het slaat net even iets te ver door.

Dat is gewoon onzin gezien het feit dat er webapps te over zijn en Safari op iOS dit ook actief ondersteund. Je kunt een website namelijk gewoon als een app icoontje op het beginscherm neerzetten. Tik je daar dan op dan opent in sommige gevallen niet de website maar een webapp versie. Instagram is daar een voorbeeld van. Dat rijmt totaal niet met jouw theorie.

Dus Apple ondersteund de basics, maar een web app begint en eindigt niet bij de mogelijkheid om een icoontje vast te pinnen en een chrome-less UI te gebruiken. Er zijn tientallen webapp API's die Apple gewoon weigert te onderstuenen voor exact de reden die @bapemania geeft.

De reden waarom Apple zo moeilijk doet over die render engine is waarom ze ook zo moeilijk doen met bepaalde frameworks en het downloaden van code. Ze vinden dat niet secure. Is overigens niet geheel ongelogen. Als we echter kritisch kijken dan kun je hier wel vragen bij zetten, het slaat net even iets te ver door.

Veiligheid? Daar hebben ze toch hun checks voor om de app store in te komen?

Oud, maar volgens mij nog wel van toepassing.

quote: https://daringfireball.net/2011/03/nitro_ios_43

The clear insinuation is that web apps running outside Mobile Safari have been made to run slower, but that’s not true. What happened with iOS 4.3 is that web apps (and JavaScript in general) running inside Mobile Safari have been made significantly faster.

The Nitro JavaScript engine is only available within Mobile Safari. Outside Mobile Safari — whether in App Store apps using the UIWebView control, or in true web apps that have been saved to the home screen — apps get iOS’s older JavaScript engine.

Put another way: nothing is slower regarding web apps or web page rendering in iOS 4.3 compared to 4.2 or earlier. If anything, everything is at least a little bit faster. But: the most significant performance improvements in iOS 4.3, particularly for JavaScript, are exclusive to Mobile Safari.

The obvious question: Why? The cynical answer is that Apple seeks to discourage the use of home screen web apps. But if that were the case, why don’t apps from the App Store get Nitro either? Many, many App Store apps use embedded UIWebView controls for displaying web content.

The real answer is about security. Perhaps the biggest reason for Nitro’s performance improvements over WebKit’s previous JavaScript engine is the use of a JIT — “Just-In-Time” compilation. Here’s Wikipedia’s page on JIT. A JIT requires the ability to mark memory pages in RAM as executable, but, iOS, as a security measure, does not allow pages in memory to be marked as executable. This is a significant and serious security policy. Most modern operating systems do allow pages in memory to be marked as executable — including Mac OS X, Windows, and (I believe) Android1. iOS 4.3 makes an exception to this policy, but the exception is specifically limited to Mobile Safari.

It’s a trade-off. Most OSes allow marking memory pages as executable for performance reasons. iOS disallows it for security reasons. If you allow for pages of memory to be escalated from writable to executable (even if you require the page be made permanently read-only first), then you are enabling the execution of unsigned native code. It breaks the chain of trust. Allowing remote code to execute locally turns every locally exploitable security flaw into a remotely exploitable one.

Apple, as of iOS 4.3, trusts Mobile Safari enough to allow this. The upside is that Mobile Safari is now significantly faster. The downside is that any security exploits against Mobile Safari now potentially allow worse things to happen than before.

Ik kan er zo 1-2-3 geen bronnen voor vinden maar ik meen me te herinneren dat WKWebView, de vervanging voor de verouderde UIWebView, wél gebruik maakt van de nieuwe JavaScript engine en JIT.

Ja, en die checks heb je dus niets aan als ieder stukje willekeurige code via de javascript engine uitgevoerd kan worden.

Ja, en die checks heb je dus niets aan als ieder stukje willekeurige code via de javascript engine uitgevoerd kan worden.

Precies; als Apple dat toe zou staan kan een ontwikkelaar achteraf de functionaliteit veranderen. Ze kunnen bijvoorbeeld, om maar iets geks te noemen, achteraf een betaalmogelijkheid buiten Apple om activeren. Gelukkig hebben we die checks

Het past niet in de Apple ideologie (die willen gewoon dat er 1 goede keuze is ipv dat gebruikers steeds lastig zouden moeten moeten switchen). Daarnaast vraag ik me af hoe mijn oude iPhone SE dat met 1Gb geheugen zou moeten gaan trekken. Iedere app een eigen browser, zoals Electron waar iedereen op desktop systemen met 16Gb al moeite mee heeft...

Het past niet in de Apple ideologie (die willen gewoon dat er 1 goede keuze is ...

Een keuze uit 1 is geen keuze.

Je hoeft het toch ook geen andere browser te gebruiken? Maar ze kunnen het wel gewoon mogelijk maken.

En apps die alleen maar een browserscherm zijn met app er in worden toch al geweerd, en gebruiken toch webkit als ze dat al doen omdat dat veruit het simpelste is. Net als op Android (daar heb je de WebView).

Maar inderdaad, die ideologie heeft wel een impact, en is ook de reden dat ik geen iOS meer gebruik. Ik kan ook bijvoorbeeld mijn OpenPGP keys niet over NFC gebruiken.

Je hoeft het toch ook geen andere browser te gebruiken? Maar ze kunnen het wel gewoon mogelijk maken.

Dit is ook omdat Apple dan bepaalde gebruikers gemakken niet meer kan garanderen. Dat zie je op MacOS ook. Ik test dit op vrijwel elke nieuwe MacBook Pro die ik koop en t is gewoon nog steeds een feit dat je met Firefox of Chrome gewoon bij lange na de beloofde accuduur niet haalt.

Safari: 10 uur browsen
Firefox: 6 uur
Chrome: 4,5 uur.

Ik heb op de laatste WWDC waar ik was uitgebreid gediscussieerd met een paar Apple Developers die daar workshops geven ook. Voor ik me begon te specialiseren in RESTAPIs geschreven in Swift hield ik me bezig met het schrijven van Adblockers voor IOS. Dit was vanaf IOS 9 mogelijk omdat Apple Swift ondersteuning hiervoor gaf. Toen hebben we uitgebreid gepraat over onder andere render engines en de een van de redenen waarom ze geen andere renderengine toestaan op IOS is omdat je op MacOS ook zien dat Zowel Mozilla als Chrome gewoon veel zwaarder zijn dan Safari (Gegeven is dat ze vaak ook net iets meer kunnen). Je haalt dan NOOIT de geadverteerde 10 uur browsen.

En dan krijg je gezeur wanneer gebruikers dus browsers met andere render engines mogen gebruiken. Telefoon snel leeg en dan is het "KUT APPLE". Telefoon langzaam? "KUT APPLE". En dit is gewoon iets waar ze zich tegen in proberen te dekken. Je moet niet vergeten dat Apple het nooit goed kan doen. Zelfs als Apple morgen 100 miljard steekt in onderzoek naar Covid zullen een berg tweakers gaan zeuren.

Dus ik als developer begrijp heel goed dat Apple t liefst alles op Webkit houd. Maarja sommige mensen hebben een andere mening.

Ik kan die redenering niet echt volgen. Wordt er op Android dan zoveel geklaagd over accuduur? Ik vind dat allemaal erg meevallen.

Op de Mac gebruik ik nooit safari maar ik zit bijna altijd aan de power dus stroomverbruik interesseert me niet. De reden is daar met name dat mijn favoriete plugins niet bestaan voor safari. Ublock origin, mijn password manager browserpass, bypass paywall zijn de belangrijkste daar. Dus safari is gewoon een non-starter.

Ook gebruik ik Mac, Windows, Linux en Android door elkaar en juist de cross platform sync van Firefox is een uitkomst. Die laatste werkt dacht ik overigens wel in de "Firefox" versie op iOS maar de plugins natuurlijk niet.

Als developer vind ik het wel prettig dat elke iPhone dezelfde engine gebruikt. En je zou denken dat websites dan ook juist altijd goed werken met elke iPhone/browser combo.

De enige reden dat ik het graag anders zou zien is dat een beetje meer concurrentie geen kwaad kan. Nu gebeurt dit gelukkig nog wel buiten het iOS platform, maar het kan geen kwaad om ook iOS daarbij te betrekken.

[quote]

Als developer vind ik het wel prettig dat elke iPhone dezelfde engine gebruikt.

Zou je dan ook liever zien dat er maar 1 engine is op Android, Windows, Linux, etc.?

Helaas gaan we daar ook naartoe

Edge is nu ook Chromium en Mozilla moet enorm bezuinigen dus veel minder ontwikkeling op Firefox gebied.

Dat is in de praktijk al zo, dus op zich. En Apple heeft zich maar te voegen bij alle standaarden die die browser op desktop en Android verzint want anders doet YouTube het ineens niet meer zo goed...

Liever niet.... Helaas wordt massaal de push naar Chromium gemaakt, terwijl ik zelf iig als gebruiker daar niet echt van onder de indruk raak qua prestaties... Heb de indruk dat het onnodig veel zwaarder is dan bv Firefox of Opera en qua geheugenverspilling kan tippen aan Internet Explorer.

Als je bedoelt dat Webkit achterloopt qua ondersteunen van standaarden had ik je gelijk kunnen geven. Maar ik doe zojuist een html5test op Safari 14 op macOS en in Safari op iOS 14. Op mac een score van 492 en op iOS van 494. Dat zegt niet meteen iets, maar je kunt niet zomaar stellen dat Safari op iOS achter loopt op die van de desktop. Dat Chrome (Score = 525) , Edge (528) en Firefox (514) voorlopen kun je weer wel stellen.

Ben het wel eens dat het mooi zou zijn als je verschillende engines zou kunnen gebruiken. Maar dan hoop ik dat Firefox de eerste is die toegelaten wordt. Want het is sowieso allemaal Blink (engine die Chrome en Edge gebruiken) wat de klok slaat.

Ja ik hoop dat ook, Firefox is het enige dat ik gebruik op alle platformen. Behalve Chrome en Edge Chromium op mijn werk (Chrome is daar de 'standaardbrowser' en Microsoft is enorm aan het lobbyen om daar Edge Chromium van te maken).

Maar dat van de standaarden bedoelde ik niet zo eens. Het is soms gewoon vervelend als een website niet goed werkt en als je geen mogelijkheid hebt om die in een andere browser te openen dan heb je echt een probleem. Apple is hier ook zelf schuldig aan: Hun eigen Apple Business Manager (business.apple.com) weigert nog steeds dienst in Firefox! Een van de weinige sites die je anno 2020 nog verplicht bepaalde browsers te gebruiken

[Reactie gewijzigd door GekkePrutser op 17 september 2020 17:25]

Vind 't op zich wel fijn dat niet Chromium óók op iOS weer de basis wordt van alle browsers. Dat is pas echt een praktische monopolie inmiddels, in ieder geval op Windows/Linux/Android. Als dat op iOS ook nog zo wordt dan kan Google er echt alles doorheen drukken.

Ik heb al meerdere applicaties gemaakt voor zowel web als mobiel die gebruik maken van browser API's die niet of slecht geïmplementeerd waren in Safari, waardoor ze gewoonweg onbruikbaar waren op iOS, dus hier sluit ik me volledig bij aan.

Het is en blijft gek dat Microsoft geen standaard browser mag forceren en een versie van hun Windows OS moet leveren zonder Internet explorer terwijl Apple andere bedrijven kan verplichten hun rendering engine te gebruiken voor hun browser.

Je zou toch zeggen dat ook hier enig sinds een mededingingskwestie aan de orde is. Immers als leverancier van software wil ik bepalen hoe die software werkt en dus ook welke libraries ik wel en niet gebruik. Dat een leverancier van een OS mij gaat verplichten om hun, in mijn ogen, minder goede rendering engine te gebruiken als ik mijn product wil aanbieden op het OS die door dat bedrijf geleverd wordt dan klopt er iets toch niet helemaal.

Maar goed het is Apple en dan is al dit soort concurrentie vervalsing helemaal goed. Immers zij kunnen en mogen andere ook verplichten 30% van hun omzet over te hevelen als ze de pech hebben dat een van hun klanten via Apple een aankoop doet, oh en als de klant een Apple device gebruikt mag je die klanten geen alternatief aan bieden.
Om die reden ook is Apple heel erg blij als er weer eens ergens een ramp gebeurt en al die brave zieltjes met behulp van hun Apple product zo veel mogelijk geld geven aan het goede doel. Want 30% is voor Apple dat is in Apple's ogen immers het beste doel.

Ik vind het jammer dat deze bedrijven gezwicht zijn voor het machtsmisbruik van Apple en nog vervelender dat Apple hier nog steeds mee weg komt.

Ik wordt anders doodgegooid met edge in windows, tot vervelens toe wordt het weer geïnstalleerd tijdens updates. Of komt er in één of andere vorm reclame voor.

[Reactie gewijzigd door Finger op 17 september 2020 20:28]

voor de duidelijkheid: al die andere browsers zijn gewoon de normale safari browser met een ander jasje. onderhuids is het gewoon safari. apple laat het dus nog steeds niet toe om andere browsers te gebruiken, alleen apps met een andere skin van hun eigen browser.

[Reactie gewijzigd door flippy op 17 september 2020 15:58]

De engine is van Safari maar alles er omheen is wel van de alternatieve browser. Extensies, synchronisatiemogelijkheden, layout etc. hebben niets met Safari te maken.

De engine is van Safari maar alles er omheen is wel van de alternatieve browser. Extensies...

Het probleem is dus dat je juist geen extensies kan installeren in bijvoorbeeld Firefox for iOS.

Unlike Firefox on Android, Firefox for iOS does not support browser add-ons.

....layout etc. hebben niets met Safari te maken.

It is the first Firefox-branded browser not to use the Gecko layout engine as is used in Firefox for desktop and mobile. Apple's policies require all iOS apps that browse the web to use the built-in WebKit rendering framework and WebKit JavaScript, so using Gecko is not possible

Behalve dat Safari niet compliant kan zijn in AzureAD.

Zou het? Als Apple dat echt wil kunnen ze het vast wel compliant maken, maar is 'compliant zijn in AzureAD' niet meer een marketingtrucje van Microsoft om je lekker in _hun_ lock-in feestje te houden?

Nee, het is gewoon een harde security eis voor veel bedrijven.

Tot de directeur een iPhone koopt meestal...

Ja? Dat is toch meestal zo?

Dit klopt niet. Je bent verplicht de standaard rendering engine (WebKit) te gebruiken, maar verder staat het je vrij wat dan ook te doen. Zo heeft Firefox traking protection, Firefox Sync, Reading lists, night mode, image blocking, een eigen password manager, noem maar op. Het is dus geen skin.

je kan een skoda motor in een audi zetten of andersom, maar het blijtt VAG. wat chromen randjes om de ventilatie veranderd daar niet veel aan.

[Reactie gewijzigd door flippy op 17 september 2020 16:33]

Een standaardbrowser die geen eigen engine mag gebruiken. Dus nog steeds een wassen neus. Maar het is een stap vooruit.

Edit: Oh. Stond die middelste alinea de hele tijd al zo in het artikel? Dan ben ik blind.

[Reactie gewijzigd door ArmEagle op 17 september 2020 15:48]

De renderengine boeit mij nou weer echt niet. Het gaat mij om de werking van sync, extensies, tabs, bookmarkbeheer etc. Daar zijn alle browsers echt wel verschillend in. Genoeg mogelijkheden om te onderscheiden ook.

Ik zou denk ik dezelfde mening hebben als Safari niet een draak van een browser zou zijn om voor te ontwikkelen. Safari is redelijk goed voor je batterij, maar er zijn veel vlakken waar Apple's engine echt achterloopt of onnodig afwijkt. Waar Chrome de moderne IE is omdat ze constant hun eigen API's doordrukken, is Safari de moderne IE omdat het eigenlijk de enige browser is waar je nog complexe workarounds voor moet schrijven. Het bedrijf waar ik werk ondersteunt Safari dan ook expliciet niet voor de meeste producten.

Firefox kan door het gebrek aan toegang tot de browserengine overigens ook geen extensies draaien op iOS (wel op Android), wat ik wel een essentiële feature vind van een browser. Ik leef bij de "Hide fixed elements" addon vanwege alle vage popups en nieuwsbriefformulieren die je op het moderne web te zien krijgt en toen Firefox zijn addons gemold had met de laatste grote Android-update merkte ik pas hoe vaak ik die feature gebruik. Ook zijn er een paar Greasemonkey-scripts die ik nog mis.

Hier heb je striktgezien natuurlijk geen engine voor nodig, maar als Apple niet eens PWA's fatsoenlijk wil ondersteunen ga ik nooit of te nimmer extensies verwachten op iOS. Voor mij is dit echt een reden om geen iPhone of iPad te kopen.

Ik ben ook nieuwsgierig naar wat voor workarounds je nodig denkt te hebben. Ik zet ze amper nog in.

Ik ben ook nieuwsgierig naar wat voor workarounds je nodig denkt te hebben. Ik zet ze amper nog in.

Je loopt af en toe nog steeds tegen leuke (lees: uiterst irritante) problemen aan met repaints die niet goed gaan in Safari. Laatst nog bezig geweest met één zo'n geval, waar een checkbox item binnen een scrollbaar element wat binnen een uitschuifmenu (side-drawer) besloot om alleen als je er mee geinteracteerd had, niet meer mee te scrollen met de rest v/d inhoud, maar op dezelfde plek te blijven painten. (En ook alleen painten: de control zelf was daadwerkelijk wel meegescrolld.)

De oplossingwork-around in dat soort gevallen is gelukkig meestal vrij simpel: transform : translate3d(0,0,0) om een gescheiden composition layer te forceren in de renderer. Alleen elke keer een kwestie van spitten op welk element je het toe moet passen om te zorgen dat je niet ergens anders weer iets sloopt.

Wat dat betreft is Safari inderdaad het nieuwe IE, want dat soort hacks stinkt naar het oude hasLayout van Internet Explorer 7 en eerder.

[Reactie gewijzigd door R4gnax op 17 september 2020 21:08]

Mm interessant dat soort bugs kom ik incidenteel nog wel eens tegen in IE11, los het vaak anders op maar wellicht dat translate3d ook kan werken.

Kun je een voorbeeld noemen van een situatie waar je een complexe workaround voor nodig had?
Ben nieuwsgierig naar wat je doet. Wellicht komt het in de toekomst van pas in mijn werk.

Het gebrek aan notificaties vanuit websites zorgde ervoor dat er in de applicatie een melding moest komen dat een langlopende taak was afgerond, bijvoorbeeld. Ook heb ik vernomen van een collega dat afbeeldingen uploaden mis ging, maar dat was alleen bij foto's ofzoiets vanwege een apart bestandsformaat van iOS; die heb ik zelf niet behandeld dus daar weet ik de details niet van. WebP avatars leken het niet goed te doen op Safari, daar was gelukkig een polyfill voor. Een bepaald onderdeel van Regex was ook niet door Safari geïmplementeerd, dat was een look behind of een lookahead (weet niet meer welke). CSS-dingen kom ik steeds minder tegen maar nog steeds heb je soms dat het er weer net niet goed uitziet. Met wat geklooi kun je daar wel omheen werken gelukkig; met CSS is er zelden maar één oplossing. Het zijn allemaal kleine dingetjes waarvan je dacht dat het onderhand wel in iedere browser zat.

Safari 14 is sinds kort uit bèta dus ik moet nog maar een keer kijken hoe het er nu voor staat. Telkens als een functie het gewoon niet goed doet, gaat het bij mij eigenlijk mis bij Safari (en dan vooral mobiel) of op de LTS van Firefox die tot voor kort op Android verspreid werd (tegenwoordig is die bij met de desktop). Met Firefox en Chrome heb ik ook soms een gevecht met kleine CSS dingetjes, maar de features missen over het algemeen niet.

Bedankt voor de toelichting.

Het is altijd wel iets met browsers, maar tegenwoordig valt er weinig te klagen.
Ik kom nog uit de tijd van framesets en tables voor layout, en scripting was er in den beginne helemaal niet. :-)

De render engine en de bijbehorende ondersteunde standaarden en technieken (en flaws) zijn daarentegen veel belangrijker om vrijheid in te hebben.

Waarom? Een ander renderengine geeft mij geen nieuwe features in de browser. Zolang de engine gewoon de standaarden zo goed mogelijk volgt zou er per definitie geen verschil moeten zijn tussen de engines.

Zolang de engine gewoon de standaarden zo goed mogelijk volgt zou er per definitie geen verschil moeten zijn tussen de engines.

En denk je dat dit gebeurt ?

Eerst: eindelijk een stap van Apple in de goeie richting, maar een kleintje.

Naast het feit dat je niet weet wat de WebKit allemaal bijhoud over jezelf. Eigen engine is ook van belang. Rendering en features kunnen anders zijn, en zijn onderdeel van de engine. Niet alles is via plugins op te lossen.

Dus graag meer Apple, ook andere engines toelaten a.u.b.

Om een of andere reden gebruikt Firefox op iPad nu de user agent string van Safari. Vroeger stond er "FxiOS" in.

De reden is om te voorkomen dat je de mobiele versie van een site krijgt. Dat is sinds iOS 13 zo.

Nee, dat is alleen maar dat hij zich identificeert als Mac. Chrome en Edge hebben nog steeds hun eigen user agent.

Zou misschien te maken kunnen hebben met het privacy beleid van Apple/Mozilla om fingerprinting tegen te gaan?

Ik gebruik Edge als standaard browser, maar ik maak wel gebruik van de beta versie, dus ik weet niet of de stable versie ook al goedgekeurd is (ik zie dat het ondertussen al toegevoegd is aan het artikel).
Daarnaast ben ik wel een issue tegengekomen, wanneer ik mijn telefoon herstart, staat Safari weer als standaard browser ingesteld.

Wat ik ook wel jammer vind, is dat hand off nog niet goed werkt. Een pagina in Edge op Mac OS wordt in iOS met Safari geopend.

[Reactie gewijzigd door mjz2cool op 17 september 2020 16:02]

Edge, Standaardbrowser instellen in iOS 14Firefox en DuckDuckGo Privacy Browser proberen zich beide te onderscheiden met privacyfuncties, meldt 9to5Mac.

Ik dacht dat Apple/Safari zichzelf al heel erg als privacy gericht positioneert. In hoeverre kunnen deze browsers dit nog overtreffen?

Waarschijnlijk doordat DDG alle mogelijke vormen van tracking blokkeert en je niet eens laat zoeken via Google en je eerst een waarschuwing geeft.

Verwijderen van social media buttons en weigeren van dingen als google analytics en FB pixels.

Tenminste. Dat denk ik.

Ah oke. Ik ken DDG van naam en weet waar ze voor staan, maar hoe en wat van hun browser weet ik niet.
Als ik het zo lees zijn ze gebaseerd op een basis van Safari, daardoor lijken de mogelijkheden me niet eindeloos en zou Apple eigenlijk alles moeten kunnen wat deze apps ook doen.

Apple zou in principe zeker alles kunnen wat deze browsers kunnen doen alleen doen ze het niet. Dit is vooral interessant voor gebruikers die windows hebben en een iPhone of iPad. Die kunnen hun bladwijzers syncen met chrome of edge en de privacy settings die ze daarin hebben gemaakt meenemen. In dat opzicht dan ook heel handig.

De brwosers zijn op safari gebaseerd voor het renderdeel. Hierdoor is de UX over alle browsers gelijk mbt page loads en ondersteuning. De andere 3 geven gewoon extra opties voor synchronisatie van van alles en DDG waarschijnlijk ook echt wel op privacy gebied.

Door niet van apple zelf te zijn, of een andere concurrent.

Ik zie de link met een betere privacy beloven dan Apple zelf al doet niet?

Apple kan dan wel dingen beloven, maar als je het niet gelooft of vertrouwt kun je nu een andere browser installeren. Dus hoe kan je betere privacy dan Apple bieden? Door niet nog meer data aan Apple te geven. ( ja ik weet het, het is iPhone, maar alle beetjes helpen)

En als je MS, Apple, en Mozilla niet vertrouwt, heb je nog DDG.

Maar Apple maakt de kernel en de rest van het OS op dat device, dus als je ze niet vertrouwt wat ben je dan aan het doen?

Door bijvoorbeeld zelf je eigen blocklists toe te kunnen voegen. Stel je wilt niks meer van de Telegraaf Media Groep zien en alle connecties naar ze blokkeren, dan is dat geen probleem bij normale browsers.

Apple werkt zulke praktijken liever tegen. Zie ook:

Beginning in 2018, Apple made technical changes to Safari's content blocking functionality which prompted backlash from users[103] and developers[104] of ad blocking extensions, who said the changes made it impossible to offer a similar level of user protection found in other browsers. Internally, the update limited the number of blocking rules[105] which could be applied by third-party extensions, preventing the full implementation of community-developed blocklists. In response, several developers of popular ad and tracking blockers announced their products were being discontinued[106], as they were now incompatible with Safari's newly-limited content blocking features. As a matter of policy, Apple requires the use of WebKit,[107] Safari's underlying rendering engine, in all browsers developed for its iOS platform, preventing users from installing any competing product which offers full ad blocking functionality. Beginning with Safari 13, popular extensions such as UBlock Origin will no longer work.
https://en.wikipedia.org/...s_and_tracking_protection

Dus echt veel schiet je er alsnog niet mee op.

Nu Brave nog. Was vanochtend erg teleurgesteld dat ik die niet als standaard browser kon instellen.

Zit BAT ook in de iOS versie? Dat zou wel eens de reden kunnen zijn.

Ze zijn ermee bezig.
https://community.brave.c...ult-browser-in-ios/162988

Dat is goed nieuws, hoop dat ze het snel voor elkaar krijgen!