[rejhgadellaa]

The difference is that, on iOS, you can't switch to a different browser that does support these features. Om very other OS you can.

A web app could ask you to use a different browser (not ideal, but if the web app requires a specific API, it's not an unreasonable).

Safari is in a very special position because it controls what the web can do on iOS (all browsers on iOS have to use Apple's WebKit engine, they can't add web features). Apple is not just gatekeeping native (through the app store), but its competition, too (the open web, through the webkit requirement)

[nerdjon]

True, but putting aside that limitation on iOS for a moment.

The very important part about this is whether or not these features are actually considered a web standard or is it Google pushing their own agenda.

Which is where whether or not any non chromium browser supports any of these on any platform. Which many of these features they don't.

That completely changes the conversation here, from Apple purposefully ignoring standards to Google pushing things that are not standards yet. Which I will admit that the reality is a bit of both here, but it should not be considered a negative when a browser does not support a feature that is non standard... we heavily criticized IE for exactly this and yet we celebrate Chrome for it?

[leptons]

>The very important part about this is whether or not these features are actually considered a web standard or is it Google pushing their own agenda.

Apple is on the W3C board that gets to decide what APIs become standards, so Apple is definitely pushing their own agenda on the W3C.

So you can't really complain that Google is pushing their own agenda with these APIs when Apple is the one refusing to make them a standard. In this case, Apple is the one doing shady shit by holding back things like web bluetooth for no good reason. No, "security" is not a reason, this API has been in use on other platforms for a very long time with no real security issues.

There are lots of other standard APIs that have been implemented, but Apple refused to let the ones that eat into their app store go forward.

>we heavily criticized IE for exactly this and yet we celebrate Chrome for it?

I remember when IE implemented XMLHTTPRequest, and it did a lot of good for the web.

I also remember when Microsoft got an antitrust case for simply bundling IE with Windows, yet Apple seems to get a pass for forbidding all other browser engines on iOS? Well, fortunately Apple has its own antitrust case in the DOJ now for its own abusive business tactics.

https://www.justice.gov/archives/opa/media/1344546/dl?inline

[nerdjon]

Google is also involved in W3C and do I really need to bring up the topics API as Google attempting to use their position to push their agenda as well?

We really need to stop putting google on a pedestal as if they are truelly on the side of an open web, like every company they are looking out for their own interests. Which is fine, they are allowed to do this.

That doesn't change that many of these are in fact not a standard according to W3C and should not be implemented in any browser until it is. A discussion about why it may not be standard is worth it, but that is also a very important distinction that is not made on this page. Right now it is framing it as google supports a standard that the other's (including Firefox) do not.

Just because Google does something it doesn't mean the rest of the industry should follow. If we did that in IE days we would still have ActiveX

[rejhgadellaa]

> many of these are in fact not a standard according to W3C and should not be implemented in any browser until it is.

That's not exactly how standards work. A browser (or anyone) comes up with a spec, a browser can ship it (to test the waters in an origin-trial, to gain traction if they believe in it), and the standard (often) comes after the fact:

"Working Groups don't gate what browsers ship, nor do they define what's useful or worthy. [...] In practice, they are thoughtful historians of recent design expeditions, critiquing, tweaking, then spreading the good news of proposals that already work through Web Standards ratified years after features first ship, serving to licence designs liberally to increase their spread."

https://infrequently.org/2025/09/standards-and-the-fall-of-i...

[troupo]

> A browser (or anyone) comes up with a spec, a browser can ship it (to test the waters in an origin-trial, to gain traction if they believe in it), and the standard (often) comes after the fact:

1. Google often doesn't bother even with a spec. Or it creates a semblance of a spec, throws it up on a googler's Github account, ships it and advertises it as "emergin standard" on web.dev

I mean, the status of many (if not most) of the APIs that these sites push are literally "napkin scribble, not on any standards track".

2. Google pushes a lot of APIs quickly into production even if there's a very explicit open objection from other browser vendors (any objections are routinely ignored: from general objections to the shape of APIs to whether it can even be implemented outside Chrome).

3. I wouldn't really quote Alex Russel on anything related to standards, as he is responsible (directly or indirectly) for quite a few of those because of his work on Web Components. E.g. Constructable Stylesheets were shipped in Chrome because Google's own lit project needed them. They shipped it in production when the design contained a trivially triggered race condition, it was called out, and Google completely ignored it because "users want it" or something.

4. Browser vendors quite literally agreed not push incompatible only-exists-in-one-browser shit after the browser wars. The whole standards process is designed to minimize this. Well, Chrome is the dominant browser, so of course they shit all over the process, and quite a few people cheer them for that.

Internet Explorer in the 2000s: shits out a bunch of own non-standard crap, people boo them

Chrome in the 2010s-2020s: shits out a bunch of own non-standard crap, people cheer and blame other browsers for not implementing this crap because... Google is "the champion of open web" or some such bullshit.

[leptons]

1. That's just your skewed take.

2. That's just your skewed take.

3. So what, bugs can be fixed. It's nowhere near as abusive as what Apple does by forcing Safari on every iOS browser.

4. You think the "browser wars" are over? Apple's actions clearly indicate the war is on, and they've selected the nuclear option of forbidding any other browser on their platform.

>Internet Explorer in the 2000s: shits out a bunch of own non-standard crap, people boo them

Did people "boo" XMLHTTPRequest? Because it actually revolutionized the web, and people cheered it.

[rejhgadellaa]

> Google often doesn't bother even with a spec.

I'm sorry, but that doesn't seem to be right. They have a process: https://www.chromium.org/blink/launching-features/

> I wouldn't really quote Alex Russel on anything related to standards

I disagree :)

...but it's getting late here, have to shut down :)

[leptons]

>Google is also involved in W3C and do I really need to bring up the topics API as Google attempting to use their position to push their agenda as well?

How is Web Bluetooth an evil agenda of Google??

It's making web browsers more capable. It's not some evil conspiracy to enrich Google. If Apple wants to let the W3C move forward in making it a standard, then all browsers would benefit, and all users that would like to use a bluetooth enabled web-app would benefit.

The only one that benefits from not allowing it to become a standard is Apple, because they get to force developers to make a native app, where Apple can extract a % of sales through the app.

>Just because Google does something it doesn't mean the rest of the industry should follow. If we did that in IE days we would still have ActiveX

IE was the first to implement XMLHTTPRequest. It changed the web fundamentally, and was the basis for "web 2.0". Everyone was glad that they created it, standards or not when it was first implemented.

If we didn't have browser manufacturers pushing the limits, we'd be stuck with "web 1.0" and browsers that did nothing interesting outside of loading animated gifs of dancing babyies.

[nerdjon]

> How is Web Bluetooth an evil agenda of Google??

Never said it was, notice how in the thing you quoted I said "Topics API"? That is extremely evil and was only introduced to benefit a single company, Google.

I never made a claim that every single thing on this list that safari does not support is a negative.

> IE was the first to implement XMLHTTPRequest. It changed the web fundamentally, and was the basis for "web 2.0".

Fantastic, that is an example of things working as they are supposed to work.

However IE also introduced things that were not made standard just as equally we celebrated that those things failed.

> If we didn't have browser manufacturers pushing the limits, we'd be stuck with "web 1.0" and browsers that did nothing interesting outside of loading animated gifs of dancing babyies.

Obviously that is true or the companies would not be involved in W3C. But that does not mean that every idea they introduce is necessary in a browser and deserves to be a standard feature. Google alone cannot and should dictate a standard, even though apparently we are fine with them attempting to do just that.

If everyone is in agreement instead of it benefiting a single company.

> The only one that benefits from not allowing it to become a standard is Apple

I would like to point out, once again. That this feature is also not available on Firefox for Android or Desktop. Your argument does not support why Mozilla has not implemented this feature. Which again, makes the "Apple bad" spin on this not as cut and dry.

[leptons]

>Google alone cannot and should dictate a standard, even though apparently we are fine with them attempting to do just that.

They did not "dictate a standard". They saw a good use case for an API and made one for it (Web Bluetooth is what I'm really focused on). If the other W3C members want changes made, then they can make suggestions, and Google or someone else can implement the changes. They can even implement their own API and have a discussion about that. Then they can put their heads together and come up with a spec everyone agrees on. That is how it normally works. Nobody "dictates" as you suggest.

Apple is flat out refusing to let Web Bluetooth move forward based on "Security rEaSoNs", and they are just shutting down the entire feature set.

Where is the security risk when users have to explicitly opt-in to use the feature? I'm sorry if your grandma clicks yes to everything, but blocking my users from the entire feature because your grandma lost her mind years ago is asinine. There is no real security threat posed by Web Bluetooth and I'd love to see you argue how there is when plenty of other existing APIs already ask for permission before you can use them. Fingerprinting can be done in a lot of other ways.

But the real crux of the problem is Apple not allowing other browser engines on their iOS platform. If that changed, I wouldn't care what one company implements or blocks in the W3C.

>I would like to point out, once again. That this feature is also not available on Firefox for Android or Desktop.

I don't care at all what Firefox does or doesn't want. Neither do most people. Firefox also does not block other browser engines from running on iOS, so people are free not to use it. Unfortunately we're not free to use the browser engines we want on iOS.