> The bashing on apple for this "to sell more apps" is nonsense, Apple originally designed and intended for HTML5 apps to beat Flash.
Whatever their apparent intention might have been ~15 years ago, it would be hard to argue that Apple puts a lot of resources into trying to protect its fiefdom. I don't think it would be all that different to suggest they (Apple) wouldn't try to control how people pay for apps by preventing app developers to offer a web-based payment option, on the basis of their past relationship with HTML5. A huge component in their success with iPhones has been control over the entire supply chain.
That said, it is a somewhat conspiratorial take that is probably better explained by laziness, bad choices, and control over proprietary UX patterns (that suck), than generalized competition, but it's not much of a reach. They also compute localStorage limits differently and have always diverged for stupid reasons
I think it's fair to say that Safari is no longer late.
That comes with 3 caveats.
1. Safari isn't updated independently of the OS, so users who don't update or whose iPhones don't get updates anymore will be forever stuck on old Safari versions.
2. Being timely on new features does little to alleviate the pain that comes from all the old messiness.
3. Different priorities driven by economic incentives of protecting their 30% cut. Fair enough. But shutting out alternative web engines on iOS is definitely a dick move.
Unfortunately this is more misdirection from Apple.
When they were asking for community input as to what developers wanted to be a part of interop 2025 that then had to go for a further non-public round with the browser makers.
Apple then proceeded to veto all of the most popular suggestions and insist that then running grep over their codebase in order to fix a comparability bug [1] with chrome and Firefox version 1 was somehow a legitimate contribution precisely so they could game the interop stats that you’re citing here.
This is misleading. The “real statistics” you link to include non-standard, Blink-only APIs like Web Bluetooth and Web USB. These are not web standards. Google proposed them and both Mozilla and Apple have rejected them on security and privacy grounds. Google have not been able to convince anybody to implement them.
Web standards are not simply whatever Google unilaterally decide they want. Standards require consensus.
> Jim once again you are jumping in to defend Apple no matter what the topic is. It’s a really strange behaviour yet again.
Is it possible for you to respond to me without personal attacks? This is the second time this week you have decided it’s appropriate to call me weird.
I have not misread anything. Web USB and Web Bluetooth are not web standards.
> This specification was published by the Web Bluetooth Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.
The specifications literally tell you they aren’t standards.
They have been rejected by both Mozilla and WebKit:
> This API provides access to the Generic Attribute Profile (GATT) of Bluetooth, which is not the lowest level of access that the specifications allow, but its generic nature makes it impossible to clearly evaluate. Like WebUSB there is significant uncertainty regarding how well prepared devices are to receive requests from arbitrary sites. The generic nature of the API means that this risk is difficult to manage. The Web Bluetooth CG has opted to only rely on user consent, which we believe is not sufficient protection. This proposal also uses a blocklist, which will require constant and active maintenance so that vulnerable devices aren't exploited. This model is unsustainable and presents a significant risk to users and their devices.
> The low-level nature of this API means that it is insecure, has a massive privacy risk, and perhaps most importantly doesn't meet the web platform's device-independence bar.
> Because many USB devices are not designed to handle potentially-malicious interactions over the USB protocols and because those devices can have significant effects on the computer they're connected to, we believe that the security risks of exposing USB devices to the Web are too broad to risk exposing users to them or to explain properly to end users to obtain meaningful informed consent. It also poses risks that sites could use USB device identity or data stored on USB devices as tracking identifiers.
> We have previously stated privacy concerns, thus the concerns: privacy label. We agree with Mozilla's security concerns raised in their standards position issue, thus the concerns: security label. This spec also depends on a specific hardware technology, and enables dependency on specific attached hardware accessories, which risks the device independence of the web; thus concerns: device-independence.
Something isn’t a web standard just because Google decided to publish a specification. No other rendering engine has accepted these specifications.
> I don’t know why you keep glossing over this no matter how many times it has been politely pointed out to you.
I don’t believe anybody has ever said this to me before, let alone repeatedly, let alone politely, but perhaps I am forgetting. Could you refresh my memory? When did this happen?
Whatever their apparent intention might have been ~15 years ago, it would be hard to argue that Apple puts a lot of resources into trying to protect its fiefdom. I don't think it would be all that different to suggest they (Apple) wouldn't try to control how people pay for apps by preventing app developers to offer a web-based payment option, on the basis of their past relationship with HTML5. A huge component in their success with iPhones has been control over the entire supply chain.
That said, it is a somewhat conspiratorial take that is probably better explained by laziness, bad choices, and control over proprietary UX patterns (that suck), than generalized competition, but it's not much of a reach. They also compute localStorage limits differently and have always diverged for stupid reasons