Alliantie van webontwikkelaars wil dat Apple andere webengines toestaat op iOS

Een groep webontwikkelaars is een alliantie gestart om te zorgen dat Apple zijn beleid aanpast als het gaat om het toelaten van webengines. De ontwikkelaars willen dat Apple andere webengines toestaat en niet alleen zijn eigen WebKit.

De groep heeft zichzelf Open Web Advocacy genoemd. Op hun website leggen de ontwikkelaars uit waarom ze het belangrijk vinden dat Apple zijn beleid aanpast. Volgens hen heeft Apple effectief andere browsers in de ban gedaan, omdat alle browsers die via de App Store worden aangeboden, gebaseerd moeten zijn op WebKit.

The Register interviewde een van de organisators van OWA, Stuart Langridge. Volgens Langridge is de groep vooral opgericht om een meer open internet na te streven. Langridge hoopt dat ze 'Apple kunnen overtuigen om andere browserengines toe te laten op iOS'. Dit zou iOS als platform ook ten goede komen, aldus Langridge.

Hoewel Apple andere browsers toelaat op iOS, zijn deze browsers volgens OWA eigenlijk niet meer dan een aangepaste versie van Safari, omdat ze allemaal op het onderliggende WebKit gebaseerd moeten zijn. Langridge hoopt dat meer ontwikkelaars zich bij de beweging aansluiten.

Niet alleen webontwikkelaars verzetten zich tegen het strenge App Store-beleid van Apple. Zo spande Epic Games een rechtszaak aan tegen het bedrijf, vanwege het verplicht gebruik moeten maken van Apples betaalsysteem. De rechter gaf Epic Games gelijk, maar Apple gaat in hoger beroep tegen de uitspraak. Ook in Nederland is er kritiek en Apple kreeg zelfs een boete van de Autoriteit Consument en Markt.

Reacties (203)

[jvanderkroon]

Als webdeveloper ben ik juist wel blij dat er maar 1 webengine op iOS is. Zo hoef je maar in 1 browser te testen.

[daanb14]

Dit argument is nou ook precies de reden, waarom we weer dreigen uit te komen op de situatie ten tijde van IE6. Een dominante browser engine, waarmee de maintainer van die engine defacto bepaalt hoe het web eruit ziet en hoe standaarden wel of niet worden geïmplementeerd. Nou vind ik het op dat punt wel lekker dat op iOS in ieder geval niet Chromium dominant is, maar de dominantie van Chromium is w.m.b. wel enorm problematisch. Helaas zijn er tegenwoordig genoeg web developers die alleen nog maar testen op Chromium of, als zij ook rekening willen houden met iOS, Chromium en WebKit. Gaat leuk worden, dat gebrek aan engines. IE6 all over again.

[Reactie gewijzigd door daanb14 op 23 juli 2024 19:12]

[wernervp]

Ik heb eigenlijk nooit problemen met Safari. Welke standaarden mis ik dan in Safari? Op https://html5test.com zie ik zeker wel dat Safari minder scoort dan Edge of Chrome, maar vergelijkbaar met Firefox.

Edit: Dat is dan wel op macOS, dus niet erg vergelijkbaar vermoed ik...

[Reactie gewijzigd door wernervp op 23 juli 2024 19:12]

[Gropah]

Op iOS ontbreken er veel APIs (voor is notificaties, nfc, en nog een sloot anderen) waardoor dingen zoals progressive webapps niet van de grond komen

[bzzzt]

Notificaties is inderdaad wel een dingetje maar niet overal nodig, maar waarom heeft een progressieve webapp NFC nodig?

[Gropah]

NFC is gewoon een manier om data uit te wisselen, net zo goed als het downloaden van een bestand of een QR code. Ik werkte op een gegeven moment voor een bedrijf, waarbij NFC ideaal zou zijn geweest. Data overdracht door op kleine afstand je telefoon te houden. Maar omdat apple dat dicht houd hebben we dat niet geimplementeerd. We zijn QR codes gaan gebruiken, maar merkte toch dat dat niet zo soepel werkte als dat we hoopten.

Laat ik de vraag terug stellen, waarom zou NFC niet open moeten zijn?

[Reactie gewijzigd door Gropah op 23 juli 2024 19:12]

[bzzzt]

Apple levert geen NFC ondersteuning, die leveren Apple pay waarvoor er een NFC chip in de iPhones zit. Als ze dat niet zouden kunnen verkopen zou de chip niet in de telefoons zitten.
Het idee dat fabrikanten verplicht zijn iedere functie van meegeleverde hardware te ondersteunen staat haaks op hoe de meeste producten tegenwoordig werken. (dan zou ik ook mijn garage kunnen dwingen mij gratis de 200pk software upgrade te geven die ze voor veel geld verkopen)

[Gropah]

Als ze dat niet zouden kunnen verkopen zou de chip niet in de telefoons zitten.

Hoe kun je dit zeker weten? En tuurlijk, er valt wat voor te zeggen dat Apple de fabrikant is en daarom enigzins kan bepalen wat ze open stellen. Maar ik vind het een enorme gemiste kans van Apple en ben het er zelf dan ook niet mee eens.

Het niet openstellen houd op dit moment letterlijk innovatie tegen, iets wat apple juist zegt aan te moedigen en voorloper in te willen zijn. Maar ja, die innovatie komt niet vanuit hun, dus dan vinden ze het juist een bedreiging en dus stellen ze het niet open.

Het idee dat fabrikanten verplicht zijn iedere functie van meegeleverde hardware te ondersteunen staat haaks op hoe de meeste producten tegenwoordig werken.

Dat is dan ook een trend waar ik moeite mee heb. Voor sommige draait het om right to repair, bij anderen om gebruik kunnen maken van hun eigendom op de manier zoals zij dat willen. De kern is dat bedrijven de limieten zetten van spullen waar je grof geld voor betaald onder het mom van veiligheid en gemak. Maar als ik daar anders over denk, dan moet ik toch wel (op eigen risico) om heen kunnen?

(dan zou ik ook mijn garage kunnen dwingen mij gratis de 200pk software upgrade te geven die ze voor veel geld verkopen)

Ik zie niet het ondersteunen van hardware leid tot gratis 200pk upgrade. Maar als jij zelf aan je motor kan en wilt prusten, op eigen risico, waarom niet?

[bzzzt]

Het niet openstellen houd op dit moment letterlijk innovatie tegen,

Oneens. Voornamelijk banken willen NFC toegang voor pinnen, en daar gaat het om 1 ding: minder aan Apple betalen, meer geld voor hun. Als klant heb je daar helemaal niks aan...
Dat is geen innovatie, dat is gewoon het wiel opnieuw uitvinden.

De kern is dat bedrijven de limieten zetten van spullen waar je grof geld voor betaald onder het mom van veiligheid en gemak. Maar als ik daar anders over denk, dan moet ik toch wel (op eigen risico) om heen kunnen?

Ligt er aan of het risico alleen voor jezelf is. Je kan je wifi router hacken voor meer vermogen, maar dat gaat ten koste van de wifi van de buren.
Of je auto fixen dat de noodrem niet zo snel af gaat waarbij je een iets groter gevaar voor anderen bent.

Ik zie niet het ondersteunen van hardware leid tot gratis 200pk upgrade. Maar als jij zelf aan je motor kan en wilt prusten, op eigen risico, waarom niet?

Mijn auto is softwarematig gelimiteerd; die kan je via een software update sneller maken. Wat jij roept is dat fabrikanten al hun hardware volledig moeten opengooien, dus dit 'afknijpen' mag dan ook niet meer.

[Gropah]

Ja, banken willen het graag open hebben zodat ze om Apple pay heen kunnen. Maar naast dat ik het zeer bedenkelijk vind dat Apple zich op deze manier in het betalingsverkeer wil voegen, zijn er ook genoeg anderen die van NFC gebruik willen maken. In de startup hoek heb ik vaak genoeg verhalen gehoord hoe NFC een goede oplossing zou zijn, maar niet gebruikt word omdat Apple het blokkeert. Daarbij zit het ook niet in elke android telefoon, maar dat word ook totaal niet gestimuleerd omdat Apple het niet open gooit, waardoor het gebruik erg gelimiteerd blijft. Dus ja, Apple houd innovatie tegen.

Over het opengooien van hardware; er zit nogal een verschil tussen volledig opengooien, inclusief documentatie en beschikbaar stellen van gereedschap, en actief tegenwerken zoals onderandere Apple doet met het linken van onderdelen en vastsolderen van onderdelen die niet vastgesoldeerd hoeven worden.

En je kunt zeggen; dat is hun goed recht. En tot een bepaalde hoogte is het ook zo. Maar op een gegeven moment kan je alleen nog maar bij Apple terecht voor reparatie doordat hun producten zo ontworpen zijn. Dat is absoluut niet een goed iets, wat al is gebleken door de reparatiepraktijken die ze nu aanhouden. Daar moet een grens aan gesteld worden. En ja, het is niet makkelijk om daar een grens in te stellen, maar ik vind het opengooien van een chip die gebruikt word om een niet propiertaire techniek mogelijk te maken geen rare.

[Reactie gewijzigd door Gropah op 23 juli 2024 19:12]

[SwaggyEggs]

Waarom zouden banken niet een beter Apple Pay alternatief op kunnen zetten?

[MenN]

Nee hoor je kunt veel meer met NFC op een iPhone. Sinds de iPhone XS ondersteund die passive nfc tags. Zo kun je bijv. shortcuts triggeren met een NFC tag.

[martijnvanegdom]

In Safari iOS zijn vooral progressieve web zaken niet geïmplementeerd.. notificaties, bepaalde file api’s.

Dit forceert je als een ontwikkelaar om een app in de App Store uit te brengen..

En daar hangt weer een inkomsten stroom aan voor Apple.

Het probleem zit ‘m niet zozeer in het afwijken standaarden zelf.. maar wel dat Apple dus gewoon bepaalde standaarden niet implementeert.

[Reactie gewijzigd door martijnvanegdom op 23 juli 2024 19:12]

[wernervp]

API's als notificaties voegen voor mij helemaal niets toe op en iOS device en eerlijke gezegd ook niet op een desktop. PWA's zit ik ook niet op te wachten, zeker niet op een iOS device. Ontwikkelaars die alleen maar een web-applicatie ontwikkelen zal ik sowieso niet snel tegenkomen op mijn iOS devices, dus wellicht dat ik er daarom geen last van heb.

Geef mij maar een goed ontwikkelde applicatie uit de AppStore.. maar goed in een tijd dat web-applicaties worden gezien als vervanging van native applicaties zal mijn mening niet erg worden gewaardeerd vermoed ik .

[TrekVogel]

Niet alles hoeft een app te zijn. Waarom zou ik voor Tweakers, nu.nl en weet ik wat allemaal een app willen? Een goede website is toch prima? Dan heb je ook geen problemen dat een bepaald os of versie geen app heeft.

[nokie]

En wat mis je nu op die websites dat niet is geimplementeerd op iOS? (Eerlijke vraag, ik merk geen verschil in “beleving” tussen iOS en PC (windows/Linux met edge/chrome/firefox)).

[TrekVogel]

Ik mis niks want ik heb geen iPhone. Maar de notificaties denk ik, verder weinig.

[wernervp]

Mee eens, de zaken die jij noemt zijn dan ook websites die prima werken zover ik weet. Ik weet niet in hoeverre die website bouwers door hoepels moeten springen voor Safari, maar wat ik hier- en daar lees zijn het voor PWA's waar Safari tekort schiet en reageert het hier- en daar wat anders op bepaalde code.

Dus, nee, voor reguliere websites hoef je geen app te hebben, maar voor applicaties gaat mijn voorkeur wel uit naar een native app die ook gebruik maakt van native componenten op het systeem. Web applicaties hebben zeker nut en kunnen ook erg handig zijn, maar het 'belang' voor een 'meer open internet' zie ik daar persoonlijk niet in. Ook het statement op de genoemde website van de alliantie: "entire future of Application Development" vind ik nogal wat overdreven. Ik snap dat webdevelopers nu steeds mee momentum krijgen op de desktop met vaak matig werkende en integrerende applicaties (Teams?), maar ik hoop dat dat niet de toekomst is van 'alle' applicatieontwikkeling.

Maar goed, ik ben voorstander van native applicaties, zeker voor applicaties waar dagelijks meerdere malen gebruik van moet maken.

[WickedStealthy]

Voila. Het interesseert mij geen moer hoe iets in elkaar gezet is zolang maar snel, efficiënt en veilig is.

[Gropah]

Veel websites waar notificaties worden aangeboden zijn het echt nonsense features. Ik hoef echt niet van een website waar ik 1 keer kom om een antwoord op een vraag te vinden, notificaties als die een nieuw artikel plaatsen. Daarom heeft het zo'n kut imago gekregen.

Het probleem met van het beperken van functionaliteit tot een app is dat je bedrijven hierdoor dwingt om een app te maken als je dat soort dingen wilt doen, maar niet iedereen kan/wil er nog een stuk software bij ontwikkelen. Vergeet niet dat er een enorm te kort aan IT'ers is en qua onderhoudbaarheid valt er ook genoeg over op te merken.

Daarnaast moet je gebruikers dan nog aan de app krijgen, en dat gaat ook niet zonder slag of stoot. PWA's zouden daar een mooie middenweg kunnen maken. Bedrijven hoeven maar 1 maar door de gebrekkige support vanuit Apple komt dat niet van de grond.

Ontwikkelaars die alleen maar een web-applicatie ontwikkelen zal ik sowieso niet snel tegenkomen op mijn iOS devices, dus wellicht dat ik er daarom geen last van heb.

De grap is dat waarschijnlijk de helft van de apps die je draait onderwater gewoon grotendeels een webapp zijn, maar dan gepackaged als iOS app met wat extra code om de randzaken te regelen.

[wernervp]

De grap is dat waarschijnlijk de helft van de apps die je draait onderwater gewoon grotendeels een webapp zijn, maar dan gepackaged als iOS app met wat extra code om de randzaken te regelen.

Dat is een feit, die apps vallen dan over het algemeen ook op door de matige kwaliteit en voor sommige toepassingen is dat ook niet niet altijd erg. Ik ben ook op de hoogte van bepaalde apps op mijn telefoon waarvoor dat geldt.

Er zijn zeker nuttige toepassingen zijn voor PWA's en mits goed uitgevoerd kan het ook een heel behoorlijke oplossing zijn. Mijn ervaring op de desktop met cross-platform, vaak op web-technologie gebaseerde applicaties is niet erg positief. Vaak zijn het resource onvriendelijke applicaties die kwa bediening afwijken van een (goede) native app, dat is op de desktop soms al frustrerend en contraproductief en op een mobiel device is dat mogelijk een factor erger. Dat geldt ook voor de bediening van die app waar vaak een middenweg wordt gekozen waardoor ze vaak niet intuïtief zijn om mee te werken.

[wernervp]

Ja ik bekijk deze pagina alleen op mijn pc/ Mac en nauwelijks mobiel. Ik begrijp alleen je reactie niet, want Tweakers werkt, net als de meeste andere website prima op Safari. Tweakers is voor mij een nieuwsbron, net als er vele andere nieuws websites zijn waar ik met regelmaat op kijk.

In het bericht van "Open Web Advocacy" spreekt men over met name de beperkingen als het gaat om cross-platform apps welke via de browser zouden moeten worden aangeboden en dat Safari daarin een beperkende factor is.

[Zoop]

Uit eigen ervaring kan ik je vertellen dat die paar procent die safari net niet ondersteund, nou juist het spul is wat je vaak tegen gaat komen (ontbreken van een aantal html5 inputs denk wel de meest prominente).

Daarnaast zijn er nog wat andere zaken dan puur de html/css/js standaarden, bijvoorbeeld de hoogte van de viewport op iOS Safari (iedereen die ooit een height:100vh heeft geprobeerd, weet wel wat ik bedoel), of hoe het renderen buiten de viewport werkt (alsin, niet, staat je image buiten beeld, wordt deze niet geladen, tenzij je hem 1 pixel net in beeld houd), of dat scroll events pas firen nadat het macos/ios momentum-scrolling helemaal klaar is en zo kan ik nog wel even doorgaan.
Dit zijn verschillen dat je een webapp hebt die het perfect doet in bijna iedere browser, maar in safari zo bugged is dat het onwerkbaar kan zijn.

Als je eenmaal de ervaring hebt met de tekortkomingen van safari, dan is dit allemaal wel recht te breien. Een beetje developer laat zich niet door safari tegenhouden in ieder geval. Maar het is wel irritant dat safari altijd die extra aandacht nodig heeft (vooral als je hacks nodig hebt om het op te lossen), terwijl de rest van de browsers prima werken als je je netjes aan standaarden houd.

[daanb14]

Wat ook verschilt is hoe browser standaarden implementeren. Ik kan mij nog herinneren van het propedeusejaar dat zelfs de manier, waarop hoogte van afbeeldingen aangegeven moest worden verschilde tussen Chromium en Firefox. Verschillende engines implementeren vaak W3C standaarden verschillend en de ene doet dit dan weer nauwkeuriger dan de ander. Geen rekening houden met die kleine verschillen zorgt er dan voor dat een website perfect werkt op Chromium, maar niet op Gecko en/of WebKit. Dat is natuurlijk een ideale manier om weer de wereld in het IE6-tijdperk te slepen.

[bzzzt]

Maar wat los je op als Apple de browserkeuze vrijgeeft? In de praktijk zit iedereen er alleen maar op te wachten om Google Chrome te installeren (wat echt de effectieve IE6 is alleen sleutelt Google er wat harder aan om de illusie te wekken dat er voortgang wordt geboekt in de browser markt).
Persoonlijk gebruik ik dagelijks Safari en heb vrijwel nooit problemen dat dingen niet goed werken. (niet meer dan in Firefox of andere browsers). Fijn dat Chrome wat meer standaarden implementeert maar die zijn niet altijd direct in het belang van de eindgebruikers.

[R4gnax]

Persoonlijk gebruik ik dagelijks Safari en heb vrijwel nooit problemen dat dingen niet goed werken.

Omdat webontwikkelaars zich achterover werken om de gaten in de features die Apple in haar browser heeft tov de concurrentie, kunstmatig gedicht te houden met alternatieve implementaties en facsimiles van de 'echte' standaard features van het web-platform; alsemde om de vele; vele bugs te omzeilen met workarounds. Eigenlijk zou iedereen voor de gein daar eens een weekje mee op moeten houden...

[Reactie gewijzigd door R4gnax op 23 juli 2024 19:12]

[bzzzt]

Mijn ervaring is dat Safari doorgaans 'niet supported' is of hooguit 'best effort'. (en ja, ik werk bij een web ontwikkelaar). Daarnaast werkt het meeste wat ontwikkelaars bedenken wat het in Chrome doet ook vrijwel altijd in Safari.
Kan je 1 voorbeeld noemen van een standaard feature die ik als gebruiker echt mis door het gedrag van Apple? (volgens mij zitten alleen advertentieboeren zich op te vreten omdat ze gebruikers niet zo goed kunnen tracken...)

[R4gnax]

Kan je 1 voorbeeld noemen van een standaard feature die ik als gebruiker echt mis door het gedrag van Apple? (volgens mij zitten alleen advertentieboeren zich op te vreten omdat ze gebruikers niet zo goed kunnen tracken...)

Heeft bijv. tijden geduurd voordat Apple de IntersectionObserver en ResizeObserver APIs geimplementeerd had die je nodig hebt om bepaalde UI interacties efficient te programmeren. Het alternatief voor die eerste is pollen op basis van scroll events, wat redelijk wat performance problemen met zich mee brengt, en wat niet de hele lading dekt. Voor de tweede is de meest efficiente aanpak om een resize te detecteren, een ranzige opzet met extra toegevoegde verborgen meetlat-elementen die intern scrollbaar zijn; een scroll offset vooringesteld hebben; en waarop het scroll event af gaat zodra ze van grootte (breedte; of hoogte) veranderen.

Je had daar voor Safari letterlijk een lap aan 400-600 ondermaats presterende code nodig, voor iets wat in alle andere browsers; ook pre-Chromium MS Edge! met 4 regels native ondersteunde API te doen is.

Godzijdank zijn ze het een jaar of 6 na-dato eindelijk eens allemaal gaan ondersteunen.

[Reactie gewijzigd door R4gnax op 23 juli 2024 19:12]

[bzzzt]

Ok, ze stellen dus andere prioriteiten. Vind het vooral een kleine ergernis en afhankelijk van je eigen prioriteit voor safari support. Het is niet dat Apple daardoor het hele internet tegenhoudt of zo...

[R4gnax]

Ok, ze stellen dus andere prioriteiten. Vind het vooral een kleine ergernis en afhankelijk van je eigen prioriteit voor safari support. Het is niet dat Apple daardoor het hele internet tegenhoudt of zo...

Je vroeg ook maar om één klein voorbeeld, heh?
Wil je de hele waslijst, lees dan bijv. de links die ik je gegeven had.

Dit gedrag van Apple is een structureel iets. En het houdt wel degelijk een rem op de doorontwikkeling van het web.

[Zezura]

Ik ben ik ben heel blij dat het juist op iOS maar een browserengine bestaat.

Belangrijkste reden; stabiliteit en energieverbruik.

[Jimbolino]

Misschien is edge wel energiezuiniger en stabieler dan de oude webkit van apple
Blijf het vreemd vinden dat er mensen zijn die juist GEEN keuzevrijheid willen, maar misschien is dat de reden dat ze graag bij Apple zitten.

[Snowfall]

Misschien is edge wel energiezuiniger en stabieler dan de oude webkit van apple

Haha nee. Op MacOS is en blijft Safari gewoon de energiezuinigste. Met Safari haal je op een Intel MacBook Pro makkelijk 8-10 uur browsen. Met Chrome ondanks Googles beloftes voor optimalisaties lange na de 6 uur niet en met Firefox haal je als je geluk hebt 4 uur. Met edge is dit niet anders en dit gaat op IOS ook niets veranderen. Het moment dat ze andere engines gaan toestaan op IOS zit je met hetzelfde probleem. Een batterij die harder leegloopt en een browser die meer systeemvereisten heeft.

[GoBieN-Be]

En dan installeer je toch geen Chrome of Firefox op je iPhone?
Als ze zoveel slechter werken dan Safari zullen maar weinig mensen ze blijven gebruiken.
Vrije keuze bevordert marktwerking en dan zorgt er in normale omstandigheden voor dat de beste het meest gebruikt wordt.

[Zezura]

Ja want dat zie je wel in al die publieke voorzieningen die de afgelopen tijd privaat zijn geworden.. het OV is beter geworden (NOT) en niet duurder, telecom e.d. Is met meer concurrentie beter geworden (NOT) ziggo & KPN zijn niet bepaald een vooruitgang. En laten we het niet hebben over gezondheidszorg of opvang.

Waarbij er is gezegd dat marktwerking en vrije keus beter zou zijn.

[Reactie gewijzigd door Zezura op 23 juli 2024 19:12]

[Remzi1993]

Ik ben ook niet voor dat geprivatiseer, maar je noemt net twee dingen op die niet echte concurrentie hebben.

OV heeft niet echte directe concurrentie alsmede als KPN en Ziggo. Wanneer KPN overal zijn glasvezelnetwerk heeft liggen dan kan er pas sprake zijn van directe concurrentie.

Zit hier met smart te wachten op glasvezel en Amsterdam staat op de planning om dit overal te doen en kan wel tot 2023/2024 duren. Ik kan hier voor de beste snelheid alleen Ziggo krijgen. Dus geen enkele concurrentie als je normale snelheden wilt.

Echte/gezonde concurrentie/marktwerking heb je pas bij minimaal 4 tot 5 partijen, die direct met elkaar concurreren.

[Reactie gewijzigd door Remzi1993 op 23 juli 2024 19:12]

[Zezura]

en gezonde concurrentie gebeurt niet want partijen kopen elkaar op of creëren een duopolie.

[Remzi1993]

Inderdaad en daarom is regulatie vereist bij een gezonde kapitalistisch maatschappij. Die regulatie is enorm verdwenen en/of verslapt, echter in Amerika is dat dus het ergst. En dit komt dus door hebberigheid bij de elite/gevestigde orde.

[Reactie gewijzigd door Remzi1993 op 23 juli 2024 19:12]

[Zezura]

Daar ben ik het mee eens.

[bommel]

Precies dat met daarbovenop het risico dat er geen echte apps meer gemaakt worden maar allerlei electron achtige rotzooi met een embedded chromium

[daanb14]

Eens. Daarom vind ik het ook een lastig punt. Aan de ene kant zou ik bijvoorbeeld graag volledige Firefox willen gebruiken op iOS, maar aan de andere kant ben ik blij dat het een van de weinig platformen is waar Chrome en Chromium niet dominant zijn.

[TheVivaldi]

Maar vreemd is het wel dat ze op macOS wél andere engines toestaan en op iOS niet. En ja, ik weet dat macOS ouder is dan iOS, maar niets staat ze in de weg om het alsnog te beperken.

[wernervp]

Maar dan is het dus beter om te pleiten voor het implementeren van standaarden dan het introduceren van alternatieve webengines voor browsers. Je kunt je ook afvragen of de standaarden dan duidelijk genoeg zijn wanner ze op verschillende manieren kunnen worden geïmplementeerd, de vraag die dan rijst is wie heeft de juiste implementatie?

Overigens heb ik niet tegen het open stellen van iOS voor andere web engines, maar liever heb ik duidelijke standaarden met duidelijke implementatie voorwaarden.. en uiteindelijk dat bedrijven zich daar aan houden. Bij IE6 was een probleem o.a. dat Microsoft zijn eigen 'standaarden' toevoegde dacht ik?

[daanb14]

Dat klopt. Ik hoop dat Google vooral niet gaat kiezen voor het negeren van de W3C. Het probleem is alleen dat dit wel makkelijker is als zo'n groot marktaandeel bij 1 engine ligt.

[killercow]

Heh? nee, HET ie6 tijdperk werd gekenmerkd doordat IE6 dominant was, en het dus niet meer boeide of zij nog ontwikkelden aan de software, of uberhaupt mee gingen in nieuwe ontwikkelingen voor het web. De klant bleef toch wel, en de web-devs konden toch geen nieuwe zaken ondersteunen, want ie6.

Juist die situatie krijg je als je maar 1 browser engine hoeft te ondersteunen. De concurentie is er dan niet meer, en daarmee de drive tot vernieuwing / bug fixes etc.

Safari op mobiel is daar het moderne schoolvoorbeeld van. De ontwikkeling gaat tergens traag, en zaken als Web App manifests, push berichten etc worden nu (bij de iphone 14) eindelijk eens geimplementeerd, letterlijk 10 of meer jaar na de concurenten. Die concurenten kunnen echter niet op Iphones meeconcureren, dus apple vindt het allemaal wel prima zo. (sterker nog, slechte webapps die functies moeten missen op iphone speelt apple's appstore natuurlijk geen parten)

Het ie6 tijdperk was dus vooral *niet* storend vanwege de kleine verschillen, het was storend vanwege de onmogelijke traagheid waarmee we vooruit konden.

Chrome is ondertussen minstens zo'n probleem aan het worden op het bredere internet, maar loopt gelukkig nog wel redelijk op tempo qua ontwikkelingen. Wellicht omdat voor google de concurentie nog met de normale native apps gewonnen moet worden.

[Rejh]

Ter illustratie; een grafiek die toont welke browser als enige een test niet haalt terwijl minstens twee andere browsers het wel goed doen:

https://twitter.com/RGade...00538640233078788/photo/1

(disclaimer; grafiek is van juli 2021)

[Aaargh!]

Dit argument is nou ook precies de reden, waarom we weer dreigen uit te komen op de situatie ten tijde van IE6. Een dominante browser engine, waarmee de maintainer van die engine defacto bepaalt hoe het web eruit ziet

Met als grote verschil dat het hier om een open-source engine gaat.

Naar mijn mening is het juist een heel goede zaak dat er maar 1 HTML render engine is. Dit is nu precies een van de dingen waar open-source perfect voor is: samen dingen bouwen die iedereen toch nodig heeft. Waarom moeten we 5 verschillende HTML render engines hebben ? Wat voegt dat toe ? Dit is nu typisch een stukje niet-sexy software die iedereen nodig heeft, en waar het dus nergens op slaat om steeds het wiel opnieuw uit te vinden. In plaats van al die developer tijd steken in meerdere engines, kan je dat beter besteden aan 1 open-source engine waar iedereen gebruik van kan maken. Ik zie eigenlijk alleen maar voordelen.

[daanb14]

Die render engine is alleen helaas wel in handen van Google. Dat lijkt mij nou niet de partij om zoveel macht over het web neer te leggen.

Edit: Ik heb het in dit geval over Blink.

[Reactie gewijzigd door daanb14 op 23 juli 2024 19:12]

[Aaargh!]

Webkit is van Apple.

[wernervp]

En Open Source: https://webkit.org/licensing-webkit/

[kiang]

Maakt helemaal niet uit in dit onderwerp: het issue is dat Apple bepaalt welke functies wel en niet werken op iOS. Dat jij zelf een fork van webkit kan maken, of een PR kan aanmaken om functionaliteit toe te voegen verandert er niets aan dat Apple bepaalt dat bvb notificaties van webapps niet werken op iOS.

Open Source is geweldig voor security onderzoek, maar de controle over wat er wel en niet in komt ligt en blijft liggen bij Apple.

[Reactie gewijzigd door kiang op 23 juli 2024 19:12]

[Jorick]

Er zal iemand het project aan moeten sturen. Google gebruikte in het verleden WebKit maar dit hebben ze op een gegeven moment geforked naar Blink. De enige reden dat dit kon is omdat het open source is. Ik zie niet in waarom Blink niet op den duur geforked zou kunnen worden door een andere partij. Punt is dat dit met IE6 nooit een optie is geweest, simpelweg omdat IE closed source was en Microsoft als enige de richting van de (toen dominante) browser kon bepalen. De vergelijking van Chromium met IE6 gaat gewoon mank.

[Gustaaf437]

Ik ben het volledig met je eens, maar de situatie is nu wel anders. WebKit is niet het wereldwijde dominante platform qua rendering, dat is Blink. Als Apple andere engines gaat toestaan op iOS zul je heel snel meer sites gaan zien met "Works best in Chrome" of iets dergelijks. Dat zie je nu al af en toe terwijl die sites altijd prima werken in Firefox of Safari (met UA spoofing).

[kimborntobewild]

Helaas zijn er tegenwoordig genoeg web developers die alleen nog maar testen op Chromium of, als zij ook rekening willen houden met iOS, Chromium en WebKit. Gaat leuk worden, dat gebrek aan engines. IE6 all over again.

Zou leuk zijn als Opera de broncode van Opera12 zou vrijgeven, zodat er een geupdate fork van Opera12 gemaakt zou kunnen worden.
Sinds Opera ook een versie van Chromium werd, mis ik Opera12 (die tegenwoordig voor veel sites niet goed meer gebruikt kan worden).
Opera heeft zichzelf de das om gedaan, door zijn browser weg te gooien en over te stappen naar iets wat slechts een ander schilletje is voor Chromium, en daarbij tientallen mogelijkheden/opties weggegooid te hebben.

[alienfruit]

Ja, daarom is Chromium engine ook een groter probleem dan WebKit. Maar inderdaad notificaties in Mobile WebKit zou fijn zijn.

[Ed Vertijsment]

Dat is wel een beetje kort door de bocht, ten tijden van IE6 waren standaarden minder ontwikkeld. Tegenwoordig houden de meeste browsers zich over het algemeen prima aan de standaarden, inclusief Chrome en Safari. En die rare vendor prefixes? Ook dat is gestandaardiseerd (https://www.w3.org/TR/CSS2/syndata.html#vendor-keywords) Dat Firefox

Probleem is echter support voor bepaalde features, HTMl/CSS/JS zijn allemaal standaarden die doorontwikkeld worden. En niet elke browser is even snel met dit implementeren. Met name op iOS is dit te regelmatig te merken. En er omdat alles op iOS op webkit moet draaien is er geen echte concurrentie en dus weinig motivatie vanuit Apple om hier iets aan te doen.

Overigens is de situatie met Chromium nog anders dan IE, Chrome wordt namelijk door verschillende partijen die de engine. gebruiken ontwikkeld. Het is dus eigenlijk gewoon een open referentie implementatie, klinkt een stuk minder eng.

[Martinspire]

Dan ben je zeker met standaard spul bezig want Apple houdt bepaalde vernieuwingen/standaarden tegen om te zorgen dat men liever een App bouwt. Dit gaat verder dan simpelweg voorkeuren.

[Zoop]

Maar Safari op iOS is dan ook wel rete irritant. Alles goed op desktop browsers? Chrome, Edge, Firefox, allemaal ok ... maarr... Safari op desktop is het huilen, al de html/css standaarden waar inmiddels iedere browser zich wel aanhoud, maar Safari? nope. En dan kom je op mobiel en kan je de mobiel specifieke problemen daar bovenop gooien. Eenmaal goed gebouwd en getest op een desktop chrome of firefox, en je zit meestal wel 99% goed voor de andere platforms. Behalve safari dus.

Safari is altijd zo'n ondergeschoven kindje geweest van Apple, wat gek is, aangezien het behoorlijk belangrijk is voor iOS ...

Meer mogelijke engines zou Apple wellicht kunnen pushen eens wat meer aandacht te schenken aan safari in het algemeen en zo niet, dan heeft men in ieder geval de keus tot iets anders.

Dat je als developer tig browsers moet testen, daar ontkom je toch niet aan (tenzij je echt enkel en alleen voor ios developed, wat me stug lijkt in het geval van web). Bij Android heb je dat sowieso al. Maar zoals ik eerder zei, over het algemeen zit je al een heel eind goed als je je aan standaarden houd en je dev werk doet in een goed ondersteunde browser. Safari zal het buitenbeentje blijven.

[84hannes]

Safari is altijd zo'n ondergeschoven kindje geweest van Apple, wat gek is, aangezien het behoorlijk belangrijk is voor iOS ...

Was ooit behoorlijk belangrijk. Bij de eerste iPhone werd Safari zelfs als argument gebruikt om geen apps de ondersteunen. Ondertussen is het andersom, met de App Store kan Apple precies controleren welke Apps wel en niet beschikbaar zijn voor iOS, welke functionaliteit wel en niet mogelijk is en welke betaalmogelijkheden gebruikers hebben. Die controle zullen ze nooit over het web hebben. Erger nog, als ze javascript-engines van derden toe gaan staan geven ze daarmee de mogelijkheid om code uit te voeren op een iOS uit handen; je bent immers niet beperkt toe het alleen uitvoeren van javascript op websites, weinig houdt je tegen om WASI te ondersteunen en een soort VM/App Store te creëren waar Apple geen enkele controle over heeft.

[Reactie gewijzigd door 84hannes op 23 juli 2024 19:12]

[Zoop]

Helemaal waar. Het originele idee van iPhone was juist om de hele webervaring gebouwd. Maar toen bleek de appstore toch behoorlijk lucratief. En alles wat enigszins de appstore kan omzeilen is a big no-no.

Hoe dan ook, dit verhaal gaat niet op voor de desktop Safari, waardoor deze browser, net als internet explorer, enkel gebruikt wordt (edit: dit is uiteraard een n=1 opmerking) om een andere browser mee te downloaden.

[Reactie gewijzigd door Zoop op 23 juli 2024 19:12]

[MrCrashdummy]

Ik denk dat veel mensen, zeker op MacBooks, Safari gebruiken. Het is sneller en minder batterij verbruik dan andere browsers op MacOS.

Als je niet veel extensies gebruikt (ben zelf helaas niet een van die mensen) is Safari een heerlijke browser

[Reactie gewijzigd door MrCrashdummy op 23 juli 2024 19:12]

[Zoop]

Dat Safari voor de gemiddelde gebruiker prima zal werken komt door de inzet van de developers die de websites en webapps maken. Die weten ook dondersgoed hoe belangrijk Safari's marktaandeel is (met name door iOS), dus de eindgebruiker-ervaring zal heus wel goed komen.

Het is daarom dan ook een alliantie van webontwikkelaars die hier om vragen, en niet, bijvoorbeeld, de consumentenbond ofzo

[Carda]

Precies.. de extensies.. de implementatie die Safari doet is echt niet fijn (understatement)

Wat betreft IOS, Safari is niet meer te updaten als je systeem niet meer te updaten is. Dat betekend dat je zit met nog een ok werkend toestel of IPad die zo lek kan zijn als een mandje omdat de browser gewoon niet meer up to date is (en de helft van de websites het niet meer doen).

[Stroper]

Anderzijds ondersteunt de mobiele Safari (sinds kort) wel extensies in tegenstelling tot bv. de mobiele Chrome.

[bzzzt]

Je weet dat Apple sinds een jaar of 2 geleden is geswitched naar hetzelfde browser extension formaat als Chrome en Firefox? (enige extra stap is dat je ze nog digitaal moet ondertekenen)

[bzzzt]

Het is heel makkelijk om te roepen dat iets stom is, maar persoonlijk heb ik zelden last van sites die het niet doen (en je gaat mij niet vertellen dat iedere ontwikkelaar standaard op Safari test!). Volgens mij moet je heel gare dingen doen (die mogelijk ook in Chrome versies over een tijdje misschien niet meer werken) voor iets echt stuk gaat.
Als Safari 'lastig' doet is het vaak ook nog omdat de ontwikkelaars iets striktere opvattingen hebben over security en privacy in gevallen waar de standaard slecht gespecificeerd is...

[Zoop]

Oh zeker wel, Safari is denk ik wel de meest geteste browser (in ieder geval bij mij) omdat iedere webdeveloper wel weet dat als het goed draait in firefox, wel goed zit in chrome, en andersom, maar dat dit absoluut niet waar is voor Safari. Ik zou zelfs durven te stellen dat je 99.99% van de browsertests te pakken hebt als je het test in een populaire browser zoals chrome, en daarnaast safari, omdat deze echt het buitenbeentje is.

Geeneen browser is perfect, elke heeft wel zijn eigen (vrij specifieke) quirks en bugs, maar safari is daar echt wel de ergste van die zo'n groot marktaandeel heeft (met name door iOS).

Dat jij persoonlijk zelden last hebt zegt een hoop over de developers en vrijwel niets over de browser.

[bzzzt]

Ik weet dat Safari niet alle standaarden ondersteunt (geen bluetooth, volledige toegang tot location en andere tracking gevoelige dingen, yay privacy), maar welke functionaliteit is er nou zo buggy dat je daar echt last van hebt? Je roept nu wel dat het zo slecht is maar een paar concrete voorbeelden zou ik dan toch op z'n minst verwachten.

[Zoop]

Had het al genoemd bij een andere reactie, maar een paar voorbeelden:

bijvoorbeeld de hoogte van de viewport op iOS Safari (iedereen die ooit een height:100vh heeft geprobeerd, weet wel wat ik bedoel), of hoe het renderen buiten de viewport werkt (alsin, niet, staat je image buiten beeld, wordt deze niet geladen, tenzij je hem 1 pixel net in beeld houd), of dat scroll events pas firen nadat het macos/ios momentum-scrolling helemaal klaar is en zo kan ik nog wel even doorgaan.

En dat zijn zaken die nog niet eens zozeer met standaarden te maken hebben, dingen die dat wel zijn zoals het ontbreken van een aantal html5 form elements (als je die gebruikt, dan geven ze je dus niet de verwachte functionaliteit), verder zijn bepaalde default styling op elementen, met name form elementen, die geen enkele andere browser heeft, altijd een border, border radius, background etc op die dingen. Kleine moeite om ze eruit te slopen, natuurlijk, maar als je een site maakt die er prima uitziet op alle browsers en zonder rekening te houden met safari, dan de eerste keer testen in safari is zeker wel schrikken hoe het er niet uit ziet en dat menig spul niet eens werkt.

Verder zijn er voor een hoop stylen die in de standaard zitten en door de andere browser allemaal netjes geïmplementeerd zijn, voor safari heb je dan nog vendor-prefixes nodig. Wat er op neer komt dat het meeste van je code en stijl universeel is, dat bijna overal werkt, maar vervolgens zit je nog zo'n 10% aan regels toe te voegen, enkel en alleen voor safari.

En dit is off the top of my head, als ik nadenk kan ik zo nog wel een paar a4tjes vullen en dan heb ik het nog amper over scripting gehad en bijna alleen over html/css. Het is ook niet zo moeilijk om even te googlen op standaard compatibiliteit van browsers en te zien dat Safari verreweg het laagste scoort onder de populaire browsers.

[R4gnax]

Het is heel makkelijk om te roepen dat iets stom is, maar persoonlijk heb ik zelden last van sites die het niet doen (en je gaat mij niet vertellen dat iedere ontwikkelaar standaard op Safari test!). Volgens mij moet je heel gare dingen doen (die mogelijk ook in Chrome versies over een tijdje misschien niet meer werken) voor iets echt stuk gaat.

Zoals een element een CSS transform animatie meegeven die triggert adhv een :hover pseudo-selector? Dit geeft namelijk in bepaalde omstandigheden op recente patch-versies van iOS 15 in Safari een gevalletje paint corruption: stukjes vh scherm waar het beeld niet correct bijgewerkt wordt.

Daar is omheen te werken door speciaal voor Safari een will-change CSS property toe te voegen, waardoor de laging van de elementen zoals deze door de compositor pipeline verwerkt wordt, anders wordt en je het probleem in kwestie side-stept.

Maar ja; zo'n extra compositor laagje kost weer extra performance; ook op andere browsers die zonder ook gewoon goed werken. Zij mogen dus ook mee 'bloeden' voor Apple. Nog los van het feit dat je hier aan het toespitsen gaat op interne implementatie-details van de browsers die als non-public beschouwd zouden moeten worden...

[Reactie gewijzigd door R4gnax op 23 juli 2024 19:12]

[bzzzt]

Vervelend als je er tegenaan loopt, maar hardly een reden om de hele browser af te schieten lijkt me. Bovendien kan je er ook gewoon voor kiezen het probleem niet te fixen (of een beetje rustig aan te doen met animaties op je site aangezien dit waarschijnlijk ook wel weer opgelost gaat worden.
Het is niet dat andere browsers geen vergelijkbare bugs hebben...

[R4gnax]

Jouw argument was dat je 'hele gare dingen moest doen.'
Bovenstaande demonstreert dat dat niet het geval is.

https://yourlogicalfallacyis.com/special-pleading

[bzzzt]

Het enige wat je aangeeft is dat er een bug in Safari zit (die mogelijk al lang gefixed is). Update: alle browsers hebben bugs. Bovendien is het geen kritische functionaliteit tenzij je de lat zo hoog legt en alles kritisch vindt en alle browsers ongeschikt zijn voor je toepassing.

[R4gnax]

Jouw argument was dat je 'hele gare dingen moest doen voordat iets echt stuk gaat.'
Wat noem jij corrupte schermuitvoer dan, als het niet 'echt stuk' is?

Nogmaals:
https://yourlogicalfallacyis.com/special-pleading

[bzzzt]

Een schoonheidsfoutje als een paar verkeerd geplaatste pixels heeft niet direct tot gevolg dat een website onbruikbaar wordt.

[Rejh]

Het probleem met Safari/WebKit is dat er letterlijk duizenden van dit soort issues zijn.

Zie deze grafiek:
https://twitter.com/RGade...00538640233078788/photo/1

Wat betreft het fixen van bugs: Safari/WebKit staat er om bekend dat ze tickets jaren lang open laten staan, vaak zonder enige reactie. Soms markeren ze een bug als gefixed, weigeren aan te geven in welke release de fix dan live zou zijn en ondertussen blijft de bug reproduceerbaar in de versie die op dat moment beschikbaar is.

[RoelRoel]

Dat vind ik best raar want als je weet wat voor mooie dingen er allemaal mogelijk zouden zijn als Apple alle features voor PWA's zou ontwikkelen in Safari zou je helemaal niet blij hiermee moeten zijn. Als webdeveloper zou je graag webapps moeten willen ontwikkelen en niet gedwongen worden om een native app te maken voor iOS omdat hun browser te beperkt is voor de wensen van de klant (bijv. pushnotificaties).

[aikebah]

ik vind dat juist een zegen als eindgebruiker. Opzouten met al die push notifications op websites.

[kimborntobewild]

ik vind dat juist een zegen als eindgebruiker. Opzouten met al die push notifications op websites.

Het punt is dat per default aan staat, dat websites een popup mogen genereren met de vraag of ze mogen pushen. Dat zou per default natuurlijk uit moeten staan. Je wordt gek van die meldingen.

[Reactie gewijzigd door kimborntobewild op 23 juli 2024 19:12]

[wernervp]

Ik sluit me hier volledig bij aan.

[Bux666]

Als webdeveloper ben ik juist wel blij dat er maar 1 webengine op iOS is. Zo hoef je maar in 1 browser te testen.

Als je als webdeveloper maar in 1 browser test, moet je echt terug naar de boeken...

[Reactie gewijzigd door Bux666 op 23 juli 2024 19:12]

[Vibonacci]

O nee hoor, je kan het ook positief bekijken.

Omdat het verschil in kwaliteit zo gigantisch is tussen iOS browsers en overige browsers, hoef je het eigenlijk alleen op een iOS browser hoeft te testen. Als het op een iOS browser werkt, dan kan je er vanzelf uit gaan dat de applicatie binnen andere browsers werkt. Je hebt de zwakste schakel getest.

[Bux666]

Wat een onzin! Precies wat daanb14 zegt: Een dominante browser engine, waarmee de maintainer van die engine defacto bepaalt hoe het web eruit ziet en hoe standaarden wel of niet worden geïmplementeerd.

Hier 2 oudere artikelen (3/4 jaar oud) die aansluiten bij wat hierboven gezegd is, alleen dan niet over WebKit maar over Chrome:

• We Need Chrome No More
• Chrome is turning into the new Internet Explorer 6

[wernervp]

Is het dan de zwakste schakel? Of betekent dit dat je eigenlijk de meest betrouwbare schakel te pakken hebt?

[killercow]

Als je alle andere schakels blindelings kunt vertrouwen, maar er eentje altijd aandacht nodig heeft.. Dan denk ik niet dat je die speciale schakel de meest betrouwbare kunt noemen.

[Arrigi]

Tja, als je schakels Chrome, Chromium met andere naam, Chromium met andere naam, Chromium met andere naam, Chromium met andere naam, Chromium met andere naam, Safari en Firefox zijn waarbij die laatste schijnbaar nog eens veel kleiner is dan Safari... Misschien is het niet zo gek dat alles dat gebaseerd is op Chromium lekker compatibel is met elkaar.

[Blokker_1999]

Ook alleen maar als je maar 1 merk telefoon wenst te ondersteunen, Maar je bent ineens ook wel gebonden aan alle beperkingen en tekortkoming van die render engine. Safari staat er nu niet om bekend om de beste rendering engine te hebben.

[t_o_c]

Gebrek aan concurrentie betekent een gebrek aan vooruitgang.

Stel je voor dat er maar een fabrikant van cpu's zou zijn. Of maar een OS. Of maar een auto fabrikant etc. Lekker makkelijk voor de ontwikkelaars en monteurs toch? Ongetwijfeld. Alleen met die instelling zouden we allemaal nog op een 386 met Dos zitten en in een Ford model T rijden.

[Mayonaise]

Probleem voor webdevelopers is dan weer dat Safari zeer traag is met het implementeren van web standards. Zo kunnen er bijvoorbeeld geen notificaties verzonden worden vanuit een web app. Ik herinner me ook dat Safari een tijd lang <input type="time" /> niet ondersteunde.

[Vibonacci]

Dit zou een optie zijn. Natuurlijk bestaat de optie voor webgebruikers om geen iOS te gebruiken altijd als alternatief.

[watercoolertje]

Natuurlijk bestaat de optie voor webgebruikers om geen iOS te gebruiken

Als webdeveloper heb je daar niet zoveel aan he?

[Reactie gewijzigd door watercoolertje op 23 juli 2024 19:12]

[bbob]

Daar komt het slappe argument altijd weer je hoeft het niet te gebruiken.

IOS en android hebben een duopolie, in USA heeft IOS zelfs 50% aandeel in mobiel. Gaat er om dat apple concurrentie de nek gewoon wil omdraaien en dat kan doen met hun dominant marktaandeel. Let wel ze doen dat op meerdere gebieden, net als andere bedrijven dat doen.

[RefriedNoodle]

...in USA heeft IOS zelfs 50% aandeel in mobiel. Gaat er om dat apple concurrentie de nek gewoon wil omdraaien en dat kan doen met hun dominant marktaandeel.

Ze hebben geen dominant marktaandeel, dus nee, ze kunnen de concurrentie de nek niet omdraaien. En nee, 50% marktaandeel (nog los van dat dat alleen de US is) is niet automatisch dominant. Een grote speler, sure, maar niet groot genoeg om in z'n eentje de dienst te kunnen uitmaken.

[bbob]

pff daar krijgen we weer de zinloze discussie
Verdeling USA google android 49% apple ios 50% samen noem je dat een duopolie en idd een duopolie.
In een duopolie heb je automatisch een dominant marktaandeel.
Lijkt me verder totaal zinloos om over dit soort definities en vastliggende marktverdelingen een discussie aan te gaan.

[RoelRoel]

Dat maakt niks uit. Het is een groot genoeg aandeel om ontwikkelaars te dwingen een native app te maken en 30% van je inkomsten van die applicatie af te staan terwijl dat niet nodig hoeft te zijn en dus bedrijven op onnodig veel kosten te jagen.

[Vibonacci]

Waarom is dat een zwak argument? Als jij weigert Safari op iOS te gebruiken, en duidelijk maakt aan andere webgebruikers waarom Safari een desastreuze keuze is, dan zal Apple's markt aandeel vanzelf dalen.

[bbob]

Apple beheert IOS en webkit is daar de enige optie, of daar sticker safari of ander op zit maakt niet uit, de basis is van apple en daar moet iedere browser bouwer het mee doen.
Het hele ios systeem is meer dan safari, dus als dat niet perfect is zal dat weinig invloed hebben op het marktaandeel.

[RoelRoel]

Op dit moment komen gewoon hele PWA-applicaties niet van de grond omdat Apple de technieken die nodig zijn om zo'n app te maken niet implementeert in Safari omdat anders de App Store op termijn voor veel minder apps nodig is en ze niet meer 30% van alle inkomsten kunnen vangen.
Als dit zo doorgaat wordt Safari de nieuwe Internet Explorer die bewust de hele ontwikkeling van het web tot stilstrand gaat brengen.

[Reactie gewijzigd door RoelRoel op 23 juli 2024 19:12]

[Vibonacci]

De achterstand (of pure dwarsboming uit arrogantie) in de PWA techniek op iOS is een perfect voorbeeld waarom je Safari, en dus door forcering van WebKit als webgebruiker, iOS moet vermijden.

Safari is al tijden de nieuwe Internet Explorer. Je moet altijd uitzonderingen maken voor deze browser. Daarnaast wordt vaak je CSS nog eens overschreven, of gedrag geforceerd dat een de maker van een web pagina niet heeft bepaald.

Waarom denk je dat ze het gebruik moeten forceren op iOS?

[wernervp]

Niet iedereen zit te wachten op die push van web-technieken voor het ontwikkelen van, over het algemeen zeer matig presterende desktop applicaties.

[bzzzt]

Maar Apple ondersteunt gewoon PWA applicaties? Misschien net die ene feature die je graag wil niet, maar beweren dat Apple de complete ontwikkeling onmogelijk maakt is flauwekul.
Zo kan je Google ook wel de schuld geven van het om zeep helpen van de adblocker markt met hun Chrome aanpassingen...

[watercoolertje]

Zo kan je Google ook wel de schuld geven van het om zeep helpen van de adblocker markt met hun Chrome aanpassingen...

Misschien moet je eens reacties bij artikelen die daarover gaan kijken (en vooral lezen), dat is namelijk precies wat er gebeurd. Dus terecht dat hier met de vinger naar Apple gewezen wordt.

[Reactie gewijzigd door watercoolertje op 23 juli 2024 19:12]

[bzzzt]

Welke artikelen?

[kipppertje]

Los van dat ik Safari prima vind werken op iOS, Microsoft werd verplicht om een browserkeuzescherm toe te voegen, omdat door de rechter geoordeeld werd dat IE standaard meeleveren oneerlijk is. Niet alleen levert Apple standaard hun eigen browser mee, maar ze maken het ook nog eens vrijwel onmogelijk om een andere te installeren.

[RefriedNoodle]

Je zegt het zelf al: een rechter heeft geoordeeld. MS is schuldig bevonden aan het misbruik maken van een monopoliepositie in één markt om een voordeel te krijgen in een andere markt.

Als iemand een rechter ervan weet te overtuigen dat Apple hetzelfde doet, dan staat Apple hetzelfde te wachten. Maar aangezien Apple bij lange na geen monopoliepositie heeft in de mobiele OS markt (en nee, een monopolie op je eigen product telt niet) zal dat zo'n vaart niet lopen.

Het hebben van een monopolie is niet strafbaar, maar daar misbruik van maken wel.

[NuEffeNiet]

Monopolie is niet nodig, aanmerkelijk marktbelang is vaak voldoende om zaken open te moeten stellen. En dat hebben ze echt wel.

[bzzzt]

Dan moet je wel eerst met een heel goed (juridisch) onderbouwd verhaal komen waarom iets opengesteld zou moeten worden. Aanmerkelijk belang is niet hetzelfde als je persoonlijke verlanglijstje kunnen inleveren.

[tailfox]

Met vrijwel bedoel je totaal onmogelijk? Er is maar 1 web engine

[kipppertje]

Hoewel een web engine een belangrijk onderdeel is, is een browser meer dan dat. Een web engine is het component wat de website rendered, alles daarom heen kun je in principe aanpassen. Een goed voorbeeld daarvan is Firefox voor iOS.

[Reactie gewijzigd door kipppertje op 23 juli 2024 19:12]

[tailfox]

Firefox installeren op een iPhone is alles behalve moeilijk alleen.

[Zoop]

Microsoft werd toen dan ook geacht een monopolist te zijn en daarom zijn dit soort maatregelen getroffen tegen Microsoft.
Wil je dat die vergelijking opgaat, dan zal je eerst moeten aantonen bij een rechter dat Apple ook een monopolist is (op de totale markt natuurlijk, niet enkel op iphones). Wat (zo ver ik weet) tot nu toe niet het geval is.

[84hannes]

Microsoft werd toen dan ook geacht een monopolist

Volgens mij was het iets minder zwart/wit, Microsoft maakte misbruik van zijn marktpositie.

[Groningerkoek]

Dat klopt, en zo'n oordeel kan er alleen zijn als het Marktaandeel daarvoor groot genoeg is.

[R4gnax]

Dat klopt, en zo'n oordeel kan er alleen zijn als het Marktaandeel daarvoor groot genoeg is.

Inderdaad; 'groot genoeg.' Dat betekent niet noodzakelijk dat ze 'de grootste' of 'één van de grootste' hoeven te zijn.

Ook bij een kleiner maar toch nog significant marktaandeel kan dat al het geval zijn, als er bijv. sprake is van een afgebakend marktaandeel dat enkel bediend kan worden via die bepaalde leverancier en het niet realistisch is dat dit aandeel op andere wijzen aangeboord kan worden of opengebroken kan worden.

Ook dan kan het misbruik van een machtspositie over dat markaandeel zijn, om via uitoefening van de macht die je over dat aandeel hebt, het aandeel gesloten te houden.

[Reactie gewijzigd door R4gnax op 23 juli 2024 19:12]

[obimk1]

Niet correct, heb op m'n iPhone Firefox geïnstalleerd en dat is mijn "standaard webbrowser".

[ChemoNL]

dat is puur een cosmetische schil (met wat extra functies) onder water gebruikt FF op iOS dezelfde engine als Safari

[obimk1]

Firefox extensions zijn superieur (veel meer keuze)

[killercow]

En de render engine (precies dat waar developers voor moeten bouwen en tegen moeten testen) is helemaal ruk, want het is safari.

[obimk1]

Ja inderdaad zo ruk dat 100% van alle webpagina's op IOS Firerfox niet renderen!

Dank je!

Ik snap het nu pas.

[killercow]

Inderdaad, 100% van de webpagina's op IOS renderen niet via firefox, maar via safari. En die engine is niet best, maar uiteraard wel getest door veel developers.
Mag jij raden waarom er een alliantie van developers klaagt over dat probleem. Dat is niet omdat safari awesome renderd en niemand het beter zou kunnen.

[Snowfall]

Mag jij raden waarom er een alliantie van developers klaagt over dat probleem.

Geld en het verkrijgen van user information die op het moment via webkit niet mogelijk zijn. Niets anders.

[Reactie gewijzigd door Snowfall op 23 juli 2024 19:12]

[obimk1]

Ik begrijp het probleem, andere browsers moeten ook die render engine gebruiken en begrijp ook deze oproep. Maar XP als je bv IE probeerde te verwijderen brak dat XP, en je kon geen andere browsers gebruiken / installeren (later wel, na een rechtszaak tegen MS). Als Apple je verplicht om een render engine te gebruiken, moet die op z'n minst 100% HTML5 compliant zijn.

[RoelRoel]

Je snapt het niet hè. Dat komt doordat ontwikkelaars er zoveel extra moeite insteken. Verder merk je ook niks van alle mogelijkheden die er niet zijn als gebruiker omdat je niet weet dat ze mogelijk zijn en ook een native app kunt downloaden waarbij de ontwikkelaar 30% van de inkomsten gedwongen moet afstaan.

[Arrigi]

Ook lang niet iedereen zit te wachten op PWAs hoor. De desktop/laptopwereld worden al jaren overspoeld met slechtgebrouwde Electron-applicaties. Lekker snel gemaakt misschien voor iemand die uit de webwereld komt, maar met achterlijke prestaties voor alle gebruikers en de batterijduur vaart er ook niet goed bij.
Het voordeel van die iOS applicaties is wel dat ze vaak een stuk beter draaien.

[Zoop]

Wat in principe een reskinned Safari is met wat Firefox features.
De vraag is of dat voldoende open is om geaccepteerd te worden als een "browserkeuze".

[bzzzt]

Het maakt in ieder geval de argumenten van mensen die vinden dat er helemaal niks te kiezen valt minder hard.

[R4gnax]

Het maakt in ieder geval de argumenten van mensen die vinden dat er helemaal niks te kiezen valt minder hard.

Je kunt 'kiezen' tussen 'shit' en 'shit met goudverf.'
Lekkere keuze.

[bzzzt]

Ik heb tot nu toe nog geen overtuigende argumenten gehoord waarom Safari nou zoveel slechter zou zijn...

[R4gnax]

https://infrequently.org/2021/04/progress-delayed/
https://httptoolkit.tech/blog/safari-is-killing-the-web/

Begin daar maar met lezen.

[Reactie gewijzigd door R4gnax op 23 juli 2024 19:12]

[bzzzt]

Die ken ik al, en ik kan het niet volledig eens zijn met die artikelen.

Ten eerste pushed Google enorm veel API's die Safari om diverse redenen (security, privacy, batterijgebruik en vast soms commerciële belangen) niet wil ondersteunen. Van mij hoeft een browser geen rechtstreekse toegang te hebben tot USB devices, maar er zijn vast mensen die dit een goed plan vinden en het waardeloos vinden dan niet iedereen dat vanaf dag 1 heeft.

Daarnaast zijn er veel ontwikkelaars die graag terug willen naar de 'IE6' situatie: iedereen op Google Chrome is ideaal als je software bouwt, maar geen wenselijke situatie vanuit marktwerking en security oogpunt.

[R4gnax]

Het gaat hier om meer -- veel meer -- dan controversiële APIs zoals die directe toegang tot USB devices willen geven. Aan het merendeel kleeft geen enkel security of privacy probleem.

Dus zullen we even niet de texas sharpshooter gaan spelen, maar naar het complete verhaal kijken?

Overigens:
directe toegang tot USB devices (wat je trouwens enkel kunt krijgen als een gebruiker daarvoor via een door de browser zelf gemanagde confirmation prompt toestemming heeft gegeven -- dus gewoon veilig!) kan in sommige gevallen verdomd handig zijn.

Ik heb ooit nog eens een gedrocht met een custom protocol handler en een speciale Windows service moeten schrijven voor een speel-en-leer apparaat dat laagdrempelig door leraren te updaten moest zijn met nieuwe software door het met USB op een PC in te prikken; in te loggen op de account op de website van de fabrikant en vanaf daar installaties door te voeren. Dat was een absolute hel om te maken. Met de Web USB APIs zou dat een peuleschil zijn geweest.

Dat jij het scenario niet ziet, betekent niet dat het er niet is.

[Reactie gewijzigd door R4gnax op 23 juli 2024 19:12]

[Rejh]

Her security argument is juist een van de redenen dat het toelaten van concurrerende engines goed zou zijn. Apple heeft een behoorlijk slechte track-record als het aankomt op "snel uitbrengen van security fixes", zie https://googleprojectzero...0to%20release%22%20column

Op dit moment is 100% van de iOS gebruikers kwetsbaar voor dezelfde security issues. Dat is dus 100% effectiviteit als je een kwetsbaarheid hebt en weet hoe je die moet exploiten. iOS heeft tot (of soms meer dan!) 50% marktaandeel in rijke westerse landen. Dat is best een lucratieve "markt".

Als er meer browsers zouden zijn is dat percentage al lager en gebruikers kunnen (tijdelijk) een veilige browser gebruiken als er zo'n kwetsbaarheid is - dan is dat percentage dus nog lager.

[wernervp]

Je kunt prima een andere browser installeren via de AppStore, alleen maken die allemaal gebruik van dezelfde redering engine. De klacht hier gaat erover dat men vindt dat die rendering engine niet voldoende de standaarden implementeert.

[Verwijderd]

Ja, laten we er een wildgroei van maken, inclusief alle security issues die ze je er bij cadeau geven.

Snap de wens, maar toch liever niet.

[Cristan]

Windows, Mac, Android & Linux hebben die "wildgroei" ook en daar is het ook geen probleem.

[Wolfos]

Alleen heeft Chrome daar zoveel marktaandeel dat je van een monopolie kunt spreken, dus "geen probleem" zou ik ook niet zeggen...

[Thonz]

Je reactie snijdt geen hout.
Safari zal op ios de meest gebruikte webbrowser blijven in deze nieuwe situatie.

[aequitas]

Ik zie de "deze website werk alleen op Chrome of Edge" berichten al verschijnen, nee dank je. Of nog erger, websites die gewoon helemaal niet meer op compatibility getest worden voor andere browsers dan Chrome.

[R4gnax]

Ik zie de "deze website werk alleen op Chrome of Edge" berichten al verschijnen, nee dank je. Of nog erger, websites die gewoon helemaal niet meer op compatibility getest worden voor andere browsers dan Chrome.

Apple Safari loopt al tijden achter op het adopteren van nieuwe gestandardiseerde features en implementeert features structureel met bugs op kritieke punten die ze alsnog vleugellam maken. En webontwikkelaars mogen het allemaal nog steeds aan elkaar geknoopt krijgen.

Eigenlijk zou men gewoon op commerciële websites een Apple-tax bovenop alle verkopen moeten gooien:
koop je vanaf een Apple, betaal je 3% meer om de extra ontwikkelkosten te dekken.

[bugcyber]

Dat is al een tijdje het geval bij verschillende Webshops.
Log je in vanop een apple device den krijg je iets hogere prijzen te zien.

zij doen dit niet wegens hogere kosten maar puur om winst, het verlies een klanten weegt niet op de extra winst voor hen. (hun redenatie die dan correct lijkt is, "apple gebruikers zijn toch gewoon om meer te betalen")

[Jan Onderwater]

Ik betaal liever met geld dan met mijn data.

[Wolfos]

Dat is op Windows / MacOS ook niet het geval met de standaard browser. Nou is gebruikers verplichten om Safari te gebruiken misschien niet de beste manier, maar een monopolie van Chrome is wel iets om voor uit te kijken.

[Martinspire]

Dit gaat ook over geïntegreerde browsers binnen apps. Daarvan ben je nu afhankelijk van Apple om bepaalde features te kunnen gebruiken. En Apple geeft Safari bewust bepaalde handicaps om te zorgen dat men apps voor de store blijft maken in plaats van via de browser diensten te verlenen.

Het gaat dus veel verder dan simpelweg een voorkeur voor andere browsers

[arjan1995]

Push notificaties in de browser is een mooi voorbeeld van iets wat praktisch elke browser kan, behalve Safari op iOS.

[Martinspire]

Jup. En het maakt dat browser apps bouwen een heel stuk lastiger worden, waardoor je al snel genoodzaakt bent om een native app te bouwen. Ik heb verder met SVG's, bepaalde CSS regels en moderne Javascript api's problemen gehad op safari dat uiteindelijk besloten werd toch geen browser app te maken, terwijl dat op Android allemaal prima werkte.

Apple werkt bewust de webdevelopers tegen en dat moet stoppen.

[watercoolertje]

Soms is het erg jammer als mensen niet gewoon lezen waar degene waar ze op reageren zelf op reageerde. Het ging specifiek over security door wildgroei. Er is dus niet gezegd dat er helemaal geen issues zijn (dus die suggestie in je reactie is overbodig) maar dat die security-issues een slechte smoes is omdat we dat nergens terugzien waar de markt wel vrij is en dus kunnen concluderen dat dat geen echt probleem is.

En het probleem wat jij dan noemt dat is nu juist van toepassing op iOS met een 100% monopolie op de engine, dat percentage kan maar 1 kant op dus het kan enkel beter worden

Of de chromium dominatie een probleem is of niet is wel een discussie waard maar waarom moet dat in een reactie over security als het daar niet op slaat?

[Reactie gewijzigd door watercoolertje op 23 juli 2024 19:12]

[watercoolertje]

De track record van Android heeft al duidelijk aangetoond dat het een issue is.

Die van iOS net zo goed hoor, of zijn al die CVE's verzonnen?

iOS en Android lekken zijn aardig in balans

[_Dune_]

Geen probleem? De laatste maanden meerdere malen gehad dat er een CVE met een score van boven de 9 gemeld wordt waardoor meerdere dagen achtereen verschillende webbrowsers gepatchen mogen worden. In onze omgeving ga ik ook liever naar één browser en de rest uitbannen (helaas hebben we het nog niet zover). Nee, alsjeblieft blijf eens van het Apple/iOS ECO-systeem af, er is genoeg keuze en mensen kiezen bewust voor iOS.

[Reactie gewijzigd door _Dune_ op 23 juli 2024 19:12]

[R4gnax]

Omgekeerd: als Apple op het moment een security-probleem in Webkit heeft zitten, kun je niet tijdelijk uitwijken naar een andere browser om je risico te minimaliseren.

[Jan Onderwater]

Denk dat Chrome daar een groter issue is.

[R4gnax]

Denk dat Chrome daar een groter issue is.

Alle platformen waar ik de echte Chrome op kan draaien, en niet enkel wat alternatief deurbeslag over Safari's Webkit, kan ik ten minste ook nog Firefox op draaien.

[Rejh]

Kanttekening hierbij is dat Apple er verreweg het langst over doet om security fixes naar gebruikers te pushen en dat dit een hele system update kost op iOS. Veel gebruikers stellen die updates uit omdat ze dan een kwartier/half uur naar een laadbalk moeten kijken en hun device niet kunnen gebruiken.

Onderstaande link geeft een beeld van de situatie. Bedenk je hierbij wel dat het gaat om dagen tussen public fix en dat het op je toestel beschikbaar is - niet de tijd vanaf het melden van een issue.

https://googleprojectzero...0to%20release%22%20column

[Zer0]

Keuze uit meer engines betekent niet dat je er niet meer voor kunt kiezen bij webkit/Safari te blijven als je denkt dat dat veiliger is.

[klakkie.57th]

En dan krijg je wederom “Works only with Chrome”.

[418O2]

"Andere webengines" betekent niet "Blind alle webengines" he... Met de onbereidwilligheid van Apple ben ik erg voor het toelaten van andere engines, maar Apple kent de wens en beweegt niet of nauwelijks mee, dus ik zie het zelf niet snel gebeuren

[Reactie gewijzigd door 418O2 op 23 juli 2024 19:12]

[Eonfge]

Je betaald er zelf de prijs voor, want met een iPhone en webkit ben jij ge-vendor-locked en die rekening komt bij jou te liggen. Als Safari zich niet competitief hoeft op te stellen, dan kan Apple software fabrikanten vanzelf duwen richting de App Store.

[geert1]

Beveiligingsproblemen kunnen zich net zo goed voordoen in een browser met webkit als engine, als die browser bijvoorbeeld ongevraagd data wegsluist naar partij x of y. De App Store-medewerkers moeten dit soort apps altijd goed doorlichten, ongeacht de engine.

Op de pc zijn er alternatieven en die zijn lang niet per definitie slechter, zoals Mozilla's Gecko engine. Ook noem ik dat geen wildgroei maar concurrentie. Het zou mooi zijn als er minstens 3 engines populair zijn, voor de innovatie en om een herhaling van "This site can only be used in Internet Explorer" te voorkomen. Google's Blink en Apple's Webkit hebben dezelfde oorsprong maar zijn nu in elk geval deels verschillend, en Gecko staat ernaast. Ik zou er eerder meer bij willen zien dan minder.

[Reactie gewijzigd door geert1 op 23 juli 2024 19:12]

[latka]

Security issues zijn een veel groter probleem met een monocultuur: een goede hack en 100% van de telefoons zijn geraakt. Dus los ervan dat safari de nieuwe ie6 is zijn er wel andere redenen te waarom het een slecht idee is. Nog los van het feit dat je op je eigen hardware je eigen software zou mogen draaien.

[kinlo]

Firefox als desktop browser gebruiken is problematisch, want dingen zoals Microsoft teams, discord etc ondersteunen die browser niet (video meeten kan bv niet met die 2 sites) en zo zijn er nog veel andere sites die slechte browsersupport hebben als je niet met chrome werkt.

Door dat Apple vasthoud aan webkit zorgen zij er voor dat nu de meeste developers op z'n minst voor 2 browsers testen/programmeren. Dit is een enorm voordeel voor mensen die niet met chrome/ium willen werken, want daardoor is er meer kans dat het werkt op hun browser

Als we nu er al niet in slagen om developers/grote bedrijven hun sites te laten werken met meerdere engines, hoe gaat dan het loslaten van webkit door Apple dit probleem dan verbeteren? Dan ga je sites krijgen die zeggen "werkt niet in safari, installeer chrome" en binnen 5 jaar zitten we weer met een enkele monopolist die alles beslist.

Ja op zich is het fout dat Apple dit doet, maar op dit ogenblik zie ik meer voor dan nadelen....

[tom.cx]

Het probleem is dat ik Chrome gewoon niet wil gebruiken. Teams werkt overigens gewoon bij mij in Firefox. Ik raad mensen ook altijd af om Chrome te gebruiken vanwege de geplande aanpassingen die Google wilt gaan doen met het verzamelen van gegevens om relevante advertenties te kunnen laten zien.

Het is daarom naar mijn idee ook problematisch dat Chrome zo groot is geworden. Ik zie daarom Chrome als de nieuwe Internet Explorer. Straks werkt geen enkele site meer goed door standaarden die alleen in Chrome zitten bijv en dat zie ik Google echt doen.

Ik snap dat ontwikkelaars het jammer vinden dat andere webengines niet toegestaan zijn. Maar dit zorgt er wel voor dat niet verplicht bent om specifiek een browser te ondersteunen en de ontwikkelingen van WebKit ook door blijven gaan .

[Marshal_Dutch]

Top, dan kan ik hopelijk in de toekomst de echte Firefox gebruiken op mijn iPhone.

[Fox Hound]

Zo spande Epic Games een rechtszaak aan tegen het bedrijf, vanwege het verplicht gebruik moeten maken van Apples betaalsysteem. De rechter gaf Epic Games gelijk, maar Apple gaat in hoger beroep tegen de uitspraak.

De uitspraak van de rechter in die zaak is veel genuanceerder dan dat hier wordt vermeld. Epic heeft op veel punten namelijk ook ongelijk gekregen dus je zou net zo goed kunnen beargumenteren dat Epic de zaak heeft verloren.

[R4gnax]

De uitspraak van de rechter in die zaak is veel genuanceerder dan dat hier wordt vermeld. Epic heeft op veel punten namelijk ook ongelijk gekregen dus je zou net zo goed kunnen beargumenteren dat Epic de zaak heeft verloren.

Het is inderdaad een mixed bag.
Ze hebben van de rechter gelijk gekregen dat Apple betalingsmethoden buiten de AppStore om moet toestaan. Ze hebben niet gelijk gekregen dat ze onder de commissie/afdracht uit kunnen komen. En ook de sancties die Apple stelde op hun overtreden van de voorwaarden voor publicatie op Apple's platform zijn overeind gebleven.

Wel is uit die zaak gebleken dat het hof van mening is dat de 30% afdracht niet op realistische zaken gestoeld is. En de uiteindelijke uitspraak bevat ook een verkapt belerend vingertje richting Epic dat ze beter daar op hadden kunnen sturen dan op het ontduiken van de afdracht. Hadden ze gestuurd op verlaging van de onrealistische afdracht, was het wss. toegekend.

O.a. Richard Hoeg van Hoeg Law gaat in hun Virtual Legality serie die op YouTube gepubliceerd wordt, hier verder op in en merkt op dat de uitspraak op z'n zachtst gezegd bijzonder geformuleerd is. Alsof de rechter letterlijk munitie voor een vervolgzaak klaar aan het zetten is geweest.

[Reactie gewijzigd door R4gnax op 23 juli 2024 19:12]

[Fox Hound]

Ironisch genoeg streeft Open Web Advocay hiermee naar een nog dominanter Chromium. Dit lijkt me niet gezond voor het web.

[Rejh]

We streven naar competitie. Competitie voor browsers en competitie tussen native en web apps (zodat App Stores een beetje van hun macht inleveren). Apple is prima in staat om te concurreren (al geloven ze er zelf niet meer zo in, heb ik soms het idee ).

Ze zijn het rijkste bedrijf ter wereld, Safari is en blijft de default engine op iOS en macOS. Dat was voor IE destijds (bijna) genoeg om het hele internet op te slokken. Een groot deel van macOS gebruikers blijft Safari gebruiken. Als Apple het dan nog verliest van Chromium, dan doen ze echt iets verkeerd.

[Akamatsu]

Vrije keus op een platform is natuurlijk altijd een plus, al snap ik wel dat Apple hier geen fan van is, omdat je hiermee natuurlijk potentiele vulnerbalities toevoegt aan het systeem. En Apple houd liever hun devices zo closed mogelijk zodat ze de integriteit van hun devices kunnen garanderen.

Hoewel ik fan ban van keuze vrijheid, moet ik zeggen dat Apple's standvastheid op bepaalde dingen wel positief is geweest in het verleden, we zijn bijvoorbeeld (mede) door Apple's aversie voor Flash eindelijk van dat security risk afgekomen.

[Rejh]

De tijd dat Apple investeerde in het web en bijna eigenhandig het einde van Flash inluidde, zijn helaas lang vervlogen. Destijds was het nota bene Steve Jobs zelf die web apps presenteerde als de manier waarop developers apps konden ontwikkelen voor iOS. Er was nog geen app store. WebKit liep voorop.

Ik heb de grafiek even niet bij de hand, maar je kunt precies zien wanneer de voorsprong van WebKit in begon te zakken t.o.v. de concurrentie: 2011, hetzelfde jaar dat Steve "wegens omstandigheden" niks meer te zeggen had bij Apple.

[BikkelZ]

Nee. Webdeveloper is een keuze die óók inhoudt dat je Netscape 4, Internet Explorer 6 of Safari moet ondersteunen naargelang het tijdvlak waarin je werkt. Er is er altijd één die het langzaamste is met nieuwe standaarden. En Mobile Safari gaat nog behoorlijk snel met nieuwe ontwikkelingen terwijl die andere browsers uit het rijtje écht stil stonden.

Zonder mobile Safari is het weer een stap dichterbij internet == Chrome, wat heel ongezond is.

[purge]

“Deze website werkt het best met …”
Dat lijkt mij juist tegengesteld aan Open Web.