I am curious why Safari in particular is getting a lot of the hate here when firefox supports even less of the features which leads me to believe that the reason many of these features have not been accepted is because they have not been accepted by the larger ecosystem and is just google pushing their own things as standard (Feels like IE days in many ways).
That being said, I am not sure why I would actually want most of these features in the browser? Many of these things feel like they further complicate what a browser is supposed to be doing and opens up security concerns at the same time.
I think the idea of using a web app for many tasks instead of apps is fine, but I don't think the idea that a web app can do everything is the way to go.
Edit: To be clear about the Firefox comment, notice that many of the features that are not supported non chromium browsers don't support on any platform. So the question on whether these are considered web standards is outside of whether iOS allows other engines.
Edit again: Apparently the third column is based on your current browser instead of always comparing chrome, mobile safari, and firefox like I assumed. I am currently on Firefox on Windows, and there are more red X's under Firefox for me. Seems like a weird choice to not always compare all major browsers.
Firefox is not in a position where it is the only browser allowed to run on a platform.
On iOS, you’re either doing a native app, sharing 30% of your income with Apple, or you’re restricted to Safari’s feature set. No browser in iOS can use anything but WebKit
It came out in the Epic trial that 90% of App Store revenue comes from loot boxes and other pay to win game mechanics - cry my a river for those companies.
The other companies that are making money from mobile are usually front end for services that don’t monetize directly through in app purchases or give you the option of not paying through the App Store.
The first million in revenue is 15% not 30%
But also if it is just Apple, why do the same companies create apps for Android?
Let’s say in this world where there was an alternative browser engine that supported everything that you wanted, how much uptake do you think you would have for your app if someone had to download an alternate browser first?
Did I also mention that in the US at least you can link out to your own payment system?
Even so, conflating "Safari is holding the web platform back by not implementing standardized web features" with "Safari is holding the Google platform back by not implementing non-standard Google features" is kind of disingenuous.
Going through some of the list from the top:
* Shortcuts in the manifest: This seems to be standard. Would be nice if mobile Safari supported it.
* Protocol Handling: This is non-standard.
* File Handling: MDN doesn't contain a reference to a standard, and it has this caveat: "At present this feature is only available on Chromium-based browsers, and only on desktop operating systems". So not only does it seem to be non-standard; Chrome on Android doesn't even support it!
* Contact Picker: This seems to be moving through the standardization process and is not yet standardized, if I understand MDN's "experimental" label correctly.
* Face Detection: This seems to be yet another not-yet-standard API.
* Vibration: This is standard, it's a shame Safari doesn't implement it.
I'll stop here but you get the point. 2/6 are actual standards; 4/6 are just features Chromium implemented even though they aren't standard.
I'm glad mobile Safari doesn't follow every Google whim. Google has enough power over the standardization process as it is; we don't want them to control which features browsers add outside of the standard too.
In addition, parts of the list seems to be extremely outdated: Safari on iOS does support the Web Push API and most of the Notifications API (at least for apps added to your home screen as PWAs). These APIs have been supported since iOS 16.4, according to MDN.
>Even so, conflating "Safari is holding the web platform back by not implementing standardized web features" with "Safari is holding the Google platform back by not implementing non-standard Google features" is kind of disingenuous.
You missed the point completely.
Apple >forbids< any browser engine on iOS other than their own Safari. So you can't just install Chrome on iOS, because when you do you get Safari instead.
I would not care how Apple cripples their own web browser if they didn't force other browsers on iOS to use their browser engine. They are forcing me to write a native app instead of just tell my customers to install Chrome to have access to the APIs my product needs (web bluetooth).
I am not an iOS app developer, I'm a web developer. I don't have the resources to support that kind of code when I already have a perfectly working web app on the competing platform. I also do not plan to sell anything through my webapp, which is why Apple wants to force developers to create a native app, where they can collect 30% (or whatever % it is now) of anything sold through the app.
It doesn't matter what the standards are or aren't. Apple are just being greedy assholes and what they are doing is absolutely worse than what Microsoft did to get sued in an antitrust case when they simply bundled IE in Windows.
And to make it worse, Apple is on the board that decides what standards get into W3C, so they are blocking useful APIs based on their own greed.
This is part of the reason Apple is currently being sued by the DOJ
Mobile safari is arguably the only thing standing between Google and total browser dominance. It's the reason why Google "only" has roughly 75% of the mobile browser market even though it has a 90% market share in desktop. I'm principally against the idea that Apple can prevent users from installing the software they want on their own devices, but we can't deny that it's better for the health of the web.
Anyway, if you want to exclusively argue "Users should be able to install the browser they want", that's fine. But you're not; both your comment and the pwa.gripe page brings up how Apple is "crippling" their own web browser. Since you use the same wording as pwa.gripe, I assume you too view the lack of non-standard Google-only features as "crippling mobile Safari". I disagree.
You seem to be conflating my opinion of "iOS's lack of browser choice has the consequence of preventing Chromium from achieving total dominance" with some imaginary other person's opinion of "iOS's lack of browser choice is a benevolent act where good guy Apple valiantly defends the open web". I do, frankly, think that mobile Safari couldn't compete that well in an open market, just like desktop Firefox can't. (Not purely because Firefox is technically inferior, mind you; products don't compete purely on technical merit.)
I think Chromium out-competing every other browser engine is a bad thing.
As the ball of mud that is web standards grows, the less likely that it becomes that things can “sort themselves out”. Even as things are you need a literal army of developers to build and maintain a modern standards compliant browser, making any real threat to Chromium dominance unlikely, and that only intensifies as Google rolls ever more crap into the katamari. If users can then be harassed into switching to Chromium based browsers it’s likely that it will never be toppled short of some new technology superseding the web entirely.
If Google abusing it’s dominant position in web browsers is a problem then the solution is legislation and anti trust action. Letting Apple abuse its own position because it currently provides benefit is not a good approach.
Same thing played out with ads and tracking a few years ago, and now look at the ads situation in the App Store.
Are you talking about Google or Apple? Because Apple is being sued by the DOJ for monopolistic and anticompetitive behavior. There are numerous examples of it spelled out in the lawsuit:
Both of them. To the extent that Google uses their position with chrome to give themselves in another domain they should be sued. Likewise, Apple refusing to allow consumers to install whatever applications they want on their own devices is so egregiously anticompetitive.
In their wildest of wet dreams Microsoft didn’t imagine they could get away with what Apple is getting away with.
I can do neither, actually. I can merely observe reality as it is and look at which forces affect the direction of the world. And right now, I observe a reality where one of the most significant forces which counteract a completely Chromium dominated web is Apple's user-hostile insistence on preventing browser engine competition on iOS.
I have very little faith in a legislative solution here since I believe politicians care about browsers, not browser engines. They see Chrome, Brave, Vivaldi, Edge and Opera and see a diverse marketplace with sufficient browser competition. They don't seem to care about the technical monoculture behind it all.
Apple doesn't even make Safari for the world's dominant platforms - Windows and Android, yet they continue to hold back progress in web browsers on all platforms to protect their own profit on their walled-garden platform.
They need to wrap up the DOJ lawsuit against Apple, but I fear the current administration will look the other way because "Tim Apple" gave the guy in charge a golden trophy. I wish I were joking.
> I think Chromium out-competing every other browser engine is a bad thing.
Hmm. I believe that Apple can compete with Google if they want to. They have the money, they have the marketing chops, they have the incentive ($20B search engine deal) and they are the default browser.
(also, they have trained iOS users that Safari is the only default browser on iOS for 14 yrs by not allowing other browsers to be set as the default)
All Apple has to do is actually compete, not just rely on their monopoly.
I mean, keeping one monopoly at bay (Chromium) with the other (WebKit requirement) isn't really how this is supposed to work, right?
> Hmm. I believe that Apple can compete with Google if they want to.
I don't think that would happen. I don't have much faith in Apple's abilities in this area, and their incentives are structured such that the less viable web apps are as a replacement to native apps, the more money they get from their 30% cut.
Again, your arguments would make sense if my opinion was: "good guy Apple valiantly defends the open web from Google out of the goodness of their hearts". But that isn't my argument. I don't care whether Apple could compete with Google if they tried. I care whether Apple would compete with Google, and they wouldn't.
> I mean, keeping one monopoly at bay (Chromium) with the other (WebKit requirement) isn't really how this is supposed to work, right?
WebKit isn't a browser monopoly, it has less than 20% of the browser market share. That 20% share is big enough to push web developers towards making websites work in browsers other than Chromium, but it's not big enough that there's a danger of web developers thinking, "everyone uses WebKit anyway so we won't bother testing on anything else".
Sure, it's a monopoly on iOS, but I don't see how this is relevant to my argument. The web is more important to me than iOS is.
> I care whether Apple would compete with Google, and they wouldn't.
They receive $20B a year from Google (search engine deal). Some estimates put WebKit/Safari's budget at $500M. That's a rounding error away from $20B of pure profits. I completely agree that Apple is not in it for the good of the web. They are in it for $20B a year.
And even if they wouldn't want to compete: fine. Let them give up. Make room for browsers that do want to compete (or at least, let them try).
> WebKit isn't a browser monopoly, it has less than 20% of the browser market share.
That monopoly on iOS is enough, though. The web has to work on iOS because the wealthiest users have an iPhone, and all they have is WebKit. I work at a place where most of our users are on mobile, and most of them are on iOS. So WebKit sets the bar for what we can do. In other words, Apple is in full control of what we are able to do. Building features for Android users is often not worth our time and money, so we just don't build it.
Letting my users have access to the Web Bluetooth API is not making Google somehow take control of the web. If Apple won't implement it, and they won't allow other browsers on their platform, that's plainly an abusive business tactic. It's far worse than what Microsoft did by simply include IE with Windows - Microsoft never forced every browser application to use Internet Explorer. Can you imagine the outrage if they did??
But somehow Apple gets a pass, and you think they're somehow saving the web? Just stop.
You're shadow boxing. I never said Apple isn't engaging in abusive business tactics. They clearly are. I just think the result benefits the open web by taking power away from Google.
And I pointed out that they don't help the open web, they stifle innovation of the web by abusing their power for profit.
Which I think is far worse than anything you think Google is trying to do.
I'm not giving Google a free pass here, sure they can be abusive, I hated "AMP" and I'm glad it got thrown on the junk pile. That was clearly abusive. But implementing Web Bluetooth? Not abusive, it's progress. And it's too bad Apple abuses their power and stifles progress in this case.
I can't say anything other than "I disagree"; I think it does help the open web. You already admitted that you in your day job has been forced to make your site work in non-Chromium browsers thanks to Apple's authoritarian stance. That's a purely good outcome in my book, as much as I dislike the lack of user freedom that's behind it.
>You already admitted that you in your day job has been forced to make your site work in non-Chromium browsers thanks to Apple's authoritarian stance.
I did not say that at all. I'm not supporting iOS at all for the features that Apple won't implement in Safari. Tough titties Apple users. And why should I? iOS and MacOS world-wide are a small percentage of all users. And Apple doesn't care what their users don't get to access, so long as Apple is making money.
Apple is not the good guy here.
They are actually doing the opposite of you want, not sure how you can't see that. "The web" is now essentially all Apple will allow it to be, for their own greedy reasons.
I don't think it does benefit the open web. If consumers can't get value from the web, they'll go where they can find it. That is currently native apps, which is a closed and proprietary ecosystem. This causes the market itself to shrink, which means fewer and fewer people will invest in the web [1].
> I do, frankly, think that mobile Safari couldn't compete that well in an open market, just like desktop Firefox can't.
Couldn't compete isn't a justification to exploit platform control and ban competition. If Apple's so worried that Safari usage will fall off in favor of Chrome, then they can invest in Safari to make it a level playing field to keep their user base.
You clearly haven’t tried to design anything complicated that has to run on safari iOS. Safari iOS is a massive piece of shit. I’ve been working on a web game for a while now using canvas and most of my pain comes from making it compatible with safari. So much stuff is broken on safari so you have to find work arounds. Like a simple but annoying one, CSS filters don’t work on canvas so you have to write all those filters your self and apply them by using imgData.
Also the constant crashing when using canvas and the web audio api, it’s a disaster to be honest and it feels intentional, like they want me to write an app instead so they can rent seek.
As a non-web developer I'm interested if anyone can answer this question:
If you're designing for <X> browser, how hard is it to make it work on <Y> browser?
Answering with at least {Chromium,Safari,Firefox}
Because if it's hard when targeting Chromium and adapting to {Safari,Firefox} but easy when targeting Safari and adapting to {Chromium,Firefox} then honestly it seems like Chromium is the problem.
What I want to distinguish is the biases in being used to programming in one environment and actual ease of programming for an arbitrary browser. Regardless of what official standards are, there are "in practice" standards, what is used in practice.
What would be nefarious is if Google is promoting people to program in ways that are not compatible with other browsers, cementing its monopoly. (This may even be achieved without explicit direction. Achievable simply by Chromium devs building tools for devs but not carrying about compatibility with other browsers). After all, the web is for everyone, but just because it's open doesn't mean monopolies/oligopolies/collusion/<other nefarious actions> can't happen.
Tdlr: does developing on chromium encourage browser incompatibility?
> Because if it's hard when targeting Chromium and adapting to {Safari,Firefox} but easy when targeting Safari and adapting to {Chromium,Firefox} then honestly it seems like Chromium is the problem.
Exactly. Test and develop against Firefox and/or Safari first and Chrome afterwards. If it’s not a true web standard and isn’t widely implemented, don’t use it.
The web worked fine for decades without smart fridge integration or whatever weird thing Google has decided that browsers must be capable of most recently.
It's not easy, though. Most of my day job is spent trying to get html interactives on an e-learning platform to work reliably with iOS's ridiculous nonstandard interaction rules around when media is allowed to play. It's worse than working with the 20 year old jsp+servlet system that serves the interactives and business logic. no other browser behaves like iOS safari and to debug and develop against it you need an ios and macos device sitting on your desk. Firefox and Firefox on Android are a breeze but a rounding-error in our usage metrics, even accounting for our development. Apple desparately hobbles the web platform to collect IAP taxes.
> with iOS's ridiculous nonstandard interaction rules around when media is allowed to play.
Are there any standard interaction rules on when media is allowed to play? I thought everyone implements it differently based on their own ideas of security and user engagement
The problem is not Google, I hate Google so I’m not white knighting them or anything but a lot of basic things are just badly implemented on iOS safari. Also if something works in chrome it probably works in Firefox as well. The only odd duck is safari and people who defend clearly have no experience trying to develop for it.
Making things work in chrome and Firefox is trivial and is never hard but when it comes to safari you have to figure out the special dance to make things work properly even when targeting it first.
No developing for chrome does not encourage browser incompatibility.
The argument which has been provided so far about why Safari is crippled is that it does not implement non-standard Chromium-only features. There are other problems with Safari, but they are not found in the page we are discussing.
I compiled a "short" list of why amd how Safari is crippled. Not entirely on topic for the post, but seems appropriate as a reply on this particular comment ;)
This article is quite literally the only one that actually discusses actual Safari problems.
And even this article falls prey to "failures in web platform tests" which are a very poor indicator. E.g. Safari passing all accessibility tests is much more important than Safari failing most accelerometer tests that only Chrome passes (because this is Chrome-only API).
Seeing that there are cross platform game engines, it seems to me that making a web game is not the best way to go. How do you plan to monetize it? Get people to put their credit card on your website? How is your web game performing on Android? Have you tested the performance on the typical mid range Android phone?
Why isn’t it the best way to go? I’m not a fan of those web game engines so I made my own.
I have various avenues of monitization; sponsored ads and letting players buy cosmetic items.
I have yet to test it on android because my priorities are making it work on desktop and iOS first and then android after. Why? because of my past experiences with making games.
Monetization? But does making your own engine “make the beer taste better”? Does it lead to a better experience for the users? Does it give you an advantage in the market?
You really don’t think you need to consider the hardware capabilities of the average Android phone?
Hint: Facebook rewrite their apps years ago to not use web based technology because performance was horrible on the average Android phone.
Yes it does because it’s optimized and efficient because there is no bloat, everything in the engine is there to serve this specific game.
I will eventually test it on android but I don’t see why it would not work with out any issues.
I wouldn’t use Facebook as a reference, I have an inside joke that they have the worst programmers. They managed to make a site that shows text and images make my computers fans spin which is honestly just embarrassing all things considered.
You really don’t see how inefficient it is running a game on a web browser compared to a game engine running native code for the platform? And you think you are going to write a better performing game engine in a web browser?
> Yes it does because it’s optimized and efficient because there is no bloat, everything in the engine is there to serve this specific game.
Everything is there to serve your game except the entire web browser.
You can still build a PWA and get most of the benefits (I use a few PWAs on my iPhone daily). Or you can package it through Expo and rely on the Reader app exception without letting users sign up on iOS (although the rules around that are changing and you might be able to).
I get the gist of the article but what specific features do you need to let people just use your app as a PWA on iOS? Do you need access to the NFC, for instance?
I need web bluetooth to give users the full experience. They can use most of my platform currently on Safari, but not the really cool stuff that web bluetooth enables.
> They are forcing me to write a native app instead of just tell my customers to install Chrome to have access to the APIs my product needs (web bluetooth).
Why don’t you encourage them to get an Android? What makes you think that people who prefer an iOS device over Android would even install Chrome after you nag them with dark patterns?
> I also do not plan to sell anything through my webapp, which is why Apple wants to force developers to create a native app, where they can collect 30% (or whatever % it is now) of anything sold through the app.
Sorry, not following you: Apple is forcing you to give them 30% of nothing? How exactly is that a problem?
> Apple are just being greedy assholes and what they are doing is absolutely worse than what Microsoft did to get sued in an antitrust case when they simply bundled IE in Windows.
Yes, how dare Apple look after their [checks notes] customers by preventing devs from using the features that would most annoy their customers?!? Such a greedy thing for a company to do, to give customers what they want! The only true purpose of a company ought to make it easy to slurp up customer data and monetize eyeballs!
That people would use Firefox on iOS. That fact. Do you know English? It seems like you understood what I said, but still had a hard time comprehending it. Are you okay?
Guess what? You not having the resources to have anything but a shitty PWA is not my problem.
Do you really think that you are going to get any level of monetization by forcing users to first download a hypothetical web browser that has all of the features you want? That web browser doesn’t exist on any mobile platform
You have no idea what my web application is, or whether it is shitty or not. So thanks for the troll - it reminds of my days on reddit, but now this pointless internet interaction is over.
No it's not. The percentage of people who actually can use alt stores is so small that nobody will really dedicate money to make browser build for iOS. Why would they when Apple would just make the work impossible anyway.
It's pure malicious compliance from Apple. Anybody defending Apple on this is simply delusional.
Browsers with alternative engines can be offered in regular AppStore. That's why I wonder why isn't this a thing. At the end of the day, browser makers probably want to reduce confusion and complexity of maintaining two vastly different applications under the same name. This most likely isn't a case of malicious compliance, you got yourself carried away here I think.
I think the main technological limitation is that other browsers cannot just-in-time compile (JIT) JavaScript or any other embedded language. Except in the EU.
ETA: your link includes JIT; I’m pointing out that that’s why they don’t exist outside of the EU. Non-JIT browsers would just not be very performant.
Now it's straight up protectionism from USA. You touch our tech margins, we won't do business with you. So yeah the regulators are unable, even if they wanted to something.
Doctorow is right when he keeps saying that countries should make it legal to jailbreak devices. The problem is that first country that tries that will get hammer from the almighty POTUS.
> why I would actually want most of these features in the browser
The page is about PWAs, applications that can be installed by the browser rather than the platform's App Store. Native applications already have those capabilities and a lot more.
Because it’s essentially propaganda. By conflating “Not Implementing something Google did” with “Intentionally Crippling”, they hope to pressure Apple by through either the general public (the PR game) or through Government mandates (the lobbying game).
This has been going for at least as long as Blink was forked off WebKit.
And why Apple? Because Apple’s the only other browser giant, and they do have motivation to not implement a lot of these features. Frankly a lot of these are features I don’t want in my fucking browser either. But web developers, and businesses that predominantly rely on the web (such as Google) want as many complex APIs as possible implemented in the browser.
Some of Mozilla's positions are based on Apple's, such as the refusal to implement Web NFC [0].
Since Webkit has been the only engine allowed on iOS, ultimately this is a disagreement on app distribution. I can see Apple and Mozilla's argument regarding Web NFC, but I also don't want to write a whole app so my friends and I can play around with NFC tags. I find it irresistible to draw comparisons to the new Android situation regarding non-Play Store apps. If there was a developer registration list for websites (that was better than DNS registrar records and TLS certificates), would Apple and Mozilla find that acceptable? After all, I need to give my real name and payment details to Apple just to write an app.
But for good measure I will add one for Mozilla too. Firefox Android still doesn't support the Web Codecs API [1], so I need to use the "jpeg" codec on Selkies remote desktop sites, which I assume is rather poor for my bandwidth and battery.
And chrome still does not support plugins on android, to my great surprise, while Safari has them on iOS. I honestly much rather have plugins than web nfc, or whatever the chrome bully decide should go in a browser.
Google’s choice to exclude extension support on Android can’t be a coincidence. Great example of conflict of interest with a web ad giant running a web browser.
It doesn't have to be an either/or situation and I certainly want both in my mobile browser!
Ad hominem is also not a valid argument against NFC. One of my friends built a whole automatic mahjong table with NFC tags. NFC apps are used in access control for offices, college dorms, apartment complexes. Businesses have obvious use cases for it, from inventory management to payments. Governments want to use NFC for government functions and visitor prearrival processing. Sure, maybe some of them want you to install apps for other reasons, but I can assure you not all of them do, so it's a shame that this function is so exclusive.
I think western users using NFC for payment, transit, gym access, etc. are not aware how apathetic the rest of the world would be if phones start taking out NFC, and one of the ultimate causes is that it's so difficult to work with across all users. It's just so much easier to make a website that shows a QR code that your PoS system or gym access gate can scan. Bottom of the barrel Android phones in India and China already ditched it and that's just going to exacerbate the issue. If it goes the way of the 3.5mm and microSD card in the next decade, we can put this in its autopsy report.
The third column is your current browser and platform, and for me it's showing Firefox on macOS missing a lot of features. When I switch over to Brave, I see Chrome on macOS. Interestingly, Chrome on macOS apparently supports vibration, despite the hardware for it being nonexistent.
But on macOS you can switch to a browser that can do all these things. A company 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)
If you ask me to run a different browser, if at all possible I’m going to use a more reasonable competitor instead. I’m not about to return to the bad old days of sites badgering me to install IE because the dev thought it was a great idea to use ActiveX or whatever.
I'm not trying to defend Apple's decisions, I'm merely pointing out that the site is showing the feature support that Firefox has or doesn't have on macOS, or whatever other platform someone is using to access the site.
No, because any browser can decide to ship a feature that it thinks is worthwhile. Users can decide which browser they trust to be their User Agent. The distribution model is open. You type a URL, you click a link. No single company in control.
> No, because any browser can decide to ship a feature that it thinks is worthwhile.
Yes, yes they can. They don't get to call it standard or essential. And Chrome-shilling sites like the pwa.gripe and a slew of others don't get to call those features "essential standards of the web".
> No single company in control.
That is literally not how standards work in the browser world by literal agreement of all browser vendors.
We literally lived through this with IE pushing its own non-standard features and calling it a day. Hence the whole "let's reach a consensus, and have several independent implementations of a feature before calling it a standard".
And if "no single company is in control", why then you're so enthusiastically pushing for a Google's full control of the web?
While true, that does not seem to align with what the checkboxes for firefox, looking at many of the ones that Safari does not support other non chromium browsers don't support on any OS. Mobile or not
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)
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?
>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.
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
> 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."
> 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.
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.
When you deliberately ignore what Google is doing, every view that is not praising Google's take over of the web is skewed.
> So what, bugs can be fixed.
No. Not on the web they can't. Once it's shipped, people depend on the functionality. That is why we're stuck with so many crappy unfixable APIs in the platform.
> Did people "boo" XMLHTTPRequest? Because it actually revolutionized the web, and people cheered it.
And yet, they didn't cheer ActiveX. For some reason you assume that every single API Google pushes out is XHR, and not ActiveX
>every view that is not praising Google's take over of the web is skewed
I am not praising Google. I'm simply pointing out that Apple is using abusive business tactics to prevent any competition. It's antitrust territory, and the DOJ agrees. I don't care which browser implements the APIs I need to access, so long as one of them does.
>No. Not on the web they can't. Once it's shipped, people depend on the functionality. That is why we're stuck with so many crappy unfixable APIs in the platform.
Just more skewed nonsense. This can and have been fixed on the web. I've had to reimplement countless APIs for all kinds of services. There are new APIs that make old ones deprecated all the time. Maybe you should try to keep up instead of stagnate like Apple is.
>And yet, they didn't cheer ActiveX. For some reason you assume that every single API Google pushes out is XHR, and not ActiveX
Just more bullshit from you. I'm tired of it. You aren't even attempting good faith arguments.
> I'm sorry, but that doesn't seem to be right. They have a process:
Yes, they do. It's their process, and their timelines. Many features on the page we're discussing are literally "drew on a napkin, not part of any standards process at all, shipped in Chrome"
>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.
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.
>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.
You continue to dwell on Bluetooth while ignoring that there are reasons to not just blindly follow Google which is what pages like this are advocating for. I honestly don't care about Bluetooth and I don't have any stakes on whether or not it is supported, and I also don't know enough about it to actually talk about security on it. I will leave that to people that actually know what they are talking about instead.
I would love if you can actually respond to Topics API and other initiatves that google has attempted that only furthers their agenda, just like you are saying Apple is doing. The fact is both companies are incentivized to do exactly that, and as I have already said both companies do this, and yet you seem to want to give Google a free pass and ignore when they have been problematic.
Regarding Firefox, them not implementing something is a very important piece of the puzzle and you cannot choose to ignore them just to try to strengthen your own argument. This is my fundamental issue with this page since they do not by default show Firefox because it completely breaks the "Apple Bad" narrative they are trying to push.
The fact is, Firefox on both mobile and desktop has not implemented many of the same API's that Safari has not and in some cases has implemented less. The Why there is extremely important because it directly impacts the conversation. Mozilla does not have any of the incentives that either Google has for pushing these features or that Apple has for not implementing them and yet they have chosen not to implement them.
I do find it quite fascinating that you have written this phrase 5 times in this thread instead of actually being able to engage in a conversation you disagree with. Frankly it's not cute.
Sure it is pointless but you also chose to start engaging in the conversation since you were confident in what you wanted to say. Just as I am.
On multiple occasions you are purposefully ignoring what people are saying and attempting to just talk about something else. I have acknowledged your bluetooth comment but you refuse to acknowledge topics api or any other instance that Google has also used their power to try to do exactly what you claim Apple is doing.
Google is not your friend, neither is Apple. And you may not care what Mozilla does but W3C does so they matter and they don't have the incentives Apple does and yet they also chose not to implement many of the same features, which you also won't acknowledge.
Safari is a monopoly on iOS and iPadOS, that's a problem if you want to make a bleeding-edge PWA app, in that it's probably not going to work very well on iPad and iPhone and there is no web alternative on those platforms.
Firefox is entirely optional, not a monopoly anywhere.
The problem for me isn't making bad web browsers, it's enforcing those bad browsers as the only option on a computer platform.
There is much more to a web browser than just its rendering engine. When you install Firefox on iOS, you get Firefox. It uses the WebKit rendering engine, but it’s still the Firefox browser.
To be frank, it’s pretty insulting and dismissive to all the people putting huge amounts of work into building browsers only to for you go around telling people that all their work is really just a mirage.
It absolutely is a mirage. It's like those Ferrari kit cars where you take a Ford or whatever car frame and remove the outer shell and put a Ferrari shell on top of it. It's not a Ferrari, it only looks like a Ferrari.
The browser engine is the majority part of the browser, everything else around it is window dressing. So when you install Firefox on iOS, you are getting Safari with a thin wrapper around it. You are not getting the Firefox rendering engine, which is the most important part of a web browser.
The problem is that it has to use the WebKit rendering engine, and not that it happens to.
I think it's more insulting to browser vendors that they have to throw away their browser engines to appease the monopolistic tendencies of one company.
I think anything that mentions Apple in a negative light gets reflexive upvotes.
I use both Apple and Android ecosystems, so I’ll occasionally participate in normal user conversations about features, how-tos, etc. Posting anything about the Android ecosystem, unless I was talking about Samsung features I disliked using, is no more or less likely to get down/upvoted than anything else I post about any other technology. Using any tone more positive than a negative-leaning neutral when referring to any Apple product reliably collects a handful of downvotes, and often a negative comment or two. Same thing with negative sentiment and upvotes. I’ve never seen such a passionate dislike of a corporation among a small number of people. Even with famous brand loyalty rivalries like Ford/Chevy in the 80s and 90s it was more mutual. It wasn’t like 99% of drivers not giving a shit, .5% of Ford users being smug, and 2% of GMC drivers just being super mad at a product they don’t own.
I don't think you're wrong, but what's especially interesting about this is that up until just a few years ago, it was completely the opposite. Giving any criticism of Apple would get so many rapid/reflexive downvotes that it often killed the comment before many people even got a change to see it. I experienced it myself a number of times. Having been reading HN now for ~13 years (I lurked for years before starting to participate), that's been my number one dislike about HN is the complete inability to have objective discussions about Apple. At one point I even wrote a quick browser extension to filter out posts that had Apple in the title because it was so nauseating. Ideally the pendulum wouldn't swing, but instead would just settle in the middle, but alas that just isn't human nature.
> Giving any criticism of Apple would get so many rapid/reflexive downvotes that it often killed the comment before many people even got a change to see it. I experienced it myself a number of times.
I’ve never found myself in any online community that meets that description. Certainly not HN, and HN hardly seems big enough to have Apple fanboy niches that you could accidentally find yourself in.
In the heyday of Steve Jobs’ Apple there was certainly a lot of praise here, but also constant prominent complaints about Apple being overpriced, or not open enough, or too litigious, or having too many fanboys.
I’ve seen way more complaints about Apple fanboyism than actual fanboyism. I’m genuinely curious how you could find yourself in one of those communities by accident.
Same. I have always found people talking about the hoards of rabid Apple fanboys but I’ve just never seen it in the wild. That’s even having been critical of Apple countless times over the years going back to the mid 90s even before Slashdot, let alone OS X. I’ve obviously seen the odd Apple fanatic out there but less frequently than , say, Linux evangelists or zealots for any given gaming platform over the past couple of decades or sports teams or cult band followers. Maybe in, like, the Apple subreddit? Brand subreddits are always where fanboys live for everything.
I think it’s a combination of underdog vibes and confirmation bias that people have adopted as a community identity.
It would be useful if the site listed whether these had been standardized outside of Chrome yet.
It’s hard to delineate which of these are Chrome features or actual web standards. And it’s therefore hard to blame either Safari or Firefox for not supporting them if they’re not standardized yet.
This is a huge list of "features from Chromium", which aren't really standard or even a thing outside of its ecosystem (the fact that both Firefox and Safari lack them is the obvious giveaway).
I'm happy that Firefox doesn't expose Bluetooth, NFC or similar stuff to websites: the browser is huge enough without needing to mediate even more access to local hardware.
It's unclear how some of these would even work for other Browser. E.g.: contacts. What data source would you use? I keep my contacts as vcard files in ~/contacts, but other folks might use a remove CalDAV server, a web-based GUI, or data stored in SQL which can be read by some other native client (I think KDE does this).
Here’s what Mozilla has to say about Web NFC, for example:
> We believe Web NFC poses risks to users security and privacy because of the wide range of functionality of the existing NFC devices on which it would be supported, because there is no system for ensuring that private information is not accidentally exposed other than relying on user consent, and because of the difficulty of meaningfully asking the user for permission to share or write data when the browser cannot explain to the user what is being shared or written.
And here’s what they have to say about Web Bluetooth:
> 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 fact is that Google wrote these specifications, couldn’t convince any other rendering engine to implement them, and somehow it’s Apple’s fault the rest of the world rejected their idea.
These are not web standards, they are Blink-only APIs that Google decided to build unilaterally. The web is not defined by whatever Google wants. Web standards are supposed to be arrived at through consensus, and the consensus is that these things should not be part of the web.
>and because of the difficulty of meaningfully asking the user for permission to share or write data when the browser cannot explain to the user what is being shared or written
So fucking moronic privacy virtue signalling BS holding technology back.
They're doing the same thing with Web Bluetooth.
"hurr de durr we can't ask permission" Yes you fucking can, you give me a modal to confirm leaving the current page and being redirected to a new one (in some cases, but not all), you give me a pop up when a site asks to send shitty notifications (as they all do).
An app can sit and use nfc/bluetooth in the background all day long...a site can only do it while I actually have it open in the browser and presumably it's foregrounded etc.
It's really, really NOT hard for them to implement this stuff & I feel like it's less "this tech that has been in phones for more than a decade is unsafe!" and more "we need to cry about features that Chrome is pushing for us to support because otherwise we're letting them lead".
>The fact is that Google wrote these specifications, couldn’t convince any other rendering engine to implement them, and somehow it’s Apple’s fault the rest of the world rejected their idea.
Apple is on the W3C board that gets to decide which APIs become standards. They are preventing these APIs from becoming standards. They have an interest to forbid Web Bluetooth and NFC from becoming standards, because they profit heavily from native apps on their iOS platform, where they collect a percentage of all sales made through apps, so they want to force developers to create native apps instead of web apps.
I'll also point out that Opera, Edge, Samsung and others did implement the Web Bluetooth API, so you are wrong about your assertion that they "couldn't convince any other rendering engine to implement them".
If you don't think Apple is abusing their power here, then you are either lacking understanding of how Apple operates, or you just love Apple a little too much.
> Apple is on the W3C board that gets to decide which APIs become standards. They are preventing these APIs from becoming standards.
They are not. You have this almost entirely backwards. To become a standard, you only need two independent interoperable implementations. This means Apple cannot block something from becoming a standard. The only thing Google needs to do is convince anybody else to implement their proposals. So far they have managed to convince precisely zero other rendering engines to do so.
> I'll also point out that Opera, Edge, Samsung and others did implement the Web Bluetooth API, so you are wrong about your assertion that they "couldn't convince any other rendering engine to implement them".
All of these are Chromium / Blink users, not independent implementations.
If Apple won't allow an API onto Safari because it competes with native apps, then why should Firefox bother to implement it? Just because something moves forward in standards, does not mean Apple will ever implement it in their browser. They may never, and so why should Firefox do so, if Apple just blocks Firefox on their platform anyway? Chrome already has the APIs I want on Android, so Firefox won't spend the money to implement a non-standard before it is a standard.
Apple has a lot more control over this situation than Firefox does, and Firefox has limited resources.
>It’s hard to delineate which of these are Chrome features or actual web standards. And it’s therefore hard to blame either Safari or Firefox for not supporting them if they’re not standardized yet.
Maybe you don't realize that Apple is on the W3C board that gets to decide which APIs become standards, so they can squash any API that they think could cut into their app store. Citing Firefox as some kind of evidence doesn't take into account the abusive business tactics that Apple uses to force developers to create native apps on their platform.
I don't care about Firefox does, because they aren't forbidding an entire platform from using any browser engine except their own browser engine, which Apple does with Safari on iOS.
So Apple controls iOS browser engines, and they also control which APIs get to become standards. This is plainly abusive. It's also part of the reason Apple is being sued by the DOJ
I'm writing this in Safari now, I'm a huge fan. There are several "features" that I actively dislike and disable in other browsers. I wonder if not being implemented in mobile safari is preventing them from being required in some webpages.
Notifications struck me as odd. I aggressively disable notifications in my apps because they are often just ads or engagement focused. But as a developer, it would be cool to have a way to notify an iOS user other than building a native app and paying the iOS tax. There's a bunch of utility apps not getting built because of this limitation.
According to this, notifications are possible if you add the app to the home screen, which I didn't know.
A feature more devs should use- I've been surprised how much websites behave like native apps if you just "add to homescreen" instead of downloading an official app, e.g. twitter, instagram.
When you open the shortcut, it doesn't launch as a tab in safari, but appears independently in the app switcher. They are often indistinguishable from official apps!
Seems like a great way for devs to avoid app store pains
iOS actually does support notifications in webapps, but only ones that have a homescreen icon. Furthermore, the notification support is different enough that I can't get my iPad to work with Android Messages for Web. So I have no clue if the API is neutered or if Google is being Google and insisting every browser be Chromium. Probably both.
WebUSB is incredibly useful to flash firmware and update configuration on random devices.
The alternative is to install random software on your computer for every device (or, if you're a Linux user, you'll likely simply be excluded and whine about it).
Making device companion utilities WebUSB means that when the hardware maker goes belly-up and their site goes down, or just decides to stop supporting a device, it's now a brick. When they are native software programs, someone can preserve them.
Just look at all the old hardware like CNC machines still running just fine on old computers, and imagine if they were connected via WebUSB instead.
WebUSB is just a terrible idea if you're not an ad company.
Not if it's an Open Source project made by a bunch of people for the love of the game. Install a PWA and you have it even when the site is down, if not code available on GH. It's possible to do on a computer (write code and distribute an app not via an app store)...but not in the magical protected-profits land of mobile devices.
Your way of thinking is the reason why we now have a half dozen trillion dollar companies controlling the world.
I’m not sure why web-midi can’t be available behind a permission to control finger printing.
I can think of several light weight patch editors I’d like be able to use. There’s probably not enough demand for someone to make a stand alone app for them.
I can’t see any reason why this needs to be controlled by apple’s app store.
Complexity for who? The user having to click "Yes I want to enable Web Bluetooth for this website"? Or for the developers? Because if it's for the developers, it's literally their job to make complex things simple for users.
But why not Bluetooth or NFC? I can’t imagine any way those could be annoyances, or even why websites would want them outside of some extremely specialized applications.
I'm personally a WebUSB, WebBT etc hater but I totally get why PWA developers want those features. For example, let's say you're manufacturing some sort of USB device and you need a way to flash drivers. The idea of being able to just make a webpage that can update your drivers is so appealing compared to having to ship apps on Windows, Mac, Linux, iOS and Android.
Similarly, if my bank website could do NFC tap-to-pay securely, that would be pretty cool. I can imagine lots of interesting opt-in uses for NFC in a webapp.
Arguments that these features are held back by Apple specifically in order to keep apps on the app store where they can control things and take 30% at least hold water, I think, even if that reasoning doesn't apply to Mozilla rejecting features.
> The idea of being able to just make a webpage that can update your drivers is so appealing compared to having to ship apps on Windows, Mac, Linux, iOS and Android.
I suspect like many here, at $work we use a shit-ton of Flexoptix SFPs.
Flexoptix are not a $megacorp, they are a (very) small German company.
They manage to ship cross-platform apps to flash the SFPs. So its really not that difficult.
I would think a web app would be more of a pain the the butt to maintain because you have to deal with CSS reactive UI etc.
For little utility apps where you don’t care to deviate from UI default appearance and behavior (and, as a user, it’s much better if you don’t anyway, though it’s very trendy to make UX worse by customizing everything) iOS and Android both are dead simple, very easy to write and maintain a utility app for either of them.
An enormous amount of the cost of developing a lot of native apps is customizing the appearance and behavior, to match some slide deck mockup or to make it “on-brand” or whatever. It’s better for the user, and way cheaper, if you just… don’t do that. Hell a lot of common UI elements are easier in native than web if you just don’t try to customize them a ton (data-backed tables and list views and such are sooooo nice)
I like WebUSB in Chrome to update my Meshtastic radios. I also like that I have to go out of my way to launch Chrome for that, and other websites can’t request permission to access local hardware in my normal browser.
Nonsense. Firefox on Android (and I'm sure everywhere else) allows endless redirects without prompting me about the redirect, sending me to sites I never wanted to go to.
And even then, where does one draw the line on "privacy"? Especially given that every other app on the user's phone is granted every permission under the sun and feeding on as much data as possible.
The core of the problem isn't supporting web bluetooth etc or not...the core of the problem is that dumbass humans will go "yes use all the permissions" because their hands are already shaking from tiktok withdrawal.
You might want your browser to do Bluetooth, NFC, Background stuff, Face Detection but I don't.
I like to use Apple products for things that are commodities to me because I am not gonna look into the details of those and when I do Apple reasoning often make sense to me (just like this list).
There is a lot more we can criticize about these big tech corps (including Apple) than a product decision for a company that is known for making polarizing decisions on behalf of their customers. If people buy it... they must like it, no?
exactly what I do. they are still annoying because providers want to me to be engaged on their terms and keep pushing these features and don’t offer a broad “never use bluetooth on any website ever” kind of option. Magic of KPIs
anyway the point here is that I don’t really care if Safari is behind in support. The article was about blaming Safari for being behind.
Gotta meet your audience where they are. As a Mobile Safari user, the foremost way I feel my use of the web is crippled is that pages assume a bigger screen or are just poorly arranged.
This of all web pages ought to be easy to read on an iPhone screen, but the way it's constructed prevents it. You can't zoom the whole page out to see the entire table width because the table is in a scrolling frame and wider than its box. You can only scroll the nested frame sideways to see how row labels relate to iPhone cells. If you give up and use landscape, it still scrolls vertically in its frame. You have to aim for the margin or else you'll scroll just an inch and be halted because you caught the table.
Because it's critical that the web be as free as it is:
• It's natural that some pages turn out like this
• So it's natural the web is a little bit shitty all over
• So it's natural the demand for richer web features is low
As far as I can see based on pwa.gripe data, between 26.3 (my version) and the newcoming 26.4 Safari on iOS gains support for five new APIs:
— Offline support
— Media capture
— Picture-in-picture
— Storage
— Speech synthesis
As well as five more APIs with caveats:
— Installation
— Notifications
— Web Push
— Barcode detection
— Speech recognition
Even taking into account that it also evidently loses support for one (audio session; I wonder if that that has to do with potential for fingerprinting), framing this feature differential between two minor(!) releases as “intentional crippling of Mobile Safari continues” strikes me as somewhat loaded.
My source is TFA, as I stated. This is what I see in the table when I follow the link.
For example, in the column for my current iOS version offline support is crossed out, and for the upcoming version it has a check mark.
If the claim being made is that pwa.gripe is a bad source, I can only assure I have nothing to do with the site. If they misinform visitors about Safari’s capabilities with regard to PWAs, you should post it as a top-level comment.
Worth noting that Apple doesn't just cripple iOS Safari, it cripples all iOS browsers because it also forces them to use WebKit, the crippled browser engine underneath Safari.
It would be fine if they just made Safari bad, that's their choice. But they don't stop there: they make the entire web bad on iOS purposely to promote the native apps they can tax.
Firefox was planning a native gecko based ios app. But Apple decided to limit it to EU forcing developers to choose to maintain seperate projects for a limited users.
Native iOS apps are sandboxed and even more secure. The reason the web engine is tied down is because web engines are insecure by nature. And now you want Apple to allow anyone to write one?
Try again. Anyone can write a browser that uses the existing web engine and connect it to any search engine they want. Make it popular enough, and they can made a deal with Google.
Having Safari is a default browser is another (valid) issue, but that is a separate concern from the web engine.
Like most people (at least on this thread). I’m okay with the vast majority of these things not supported in mobile safari. But man, Bluetooth would be nice. I often provision esp32 devices for various things and either I need an app or a laptop when my phone is perfectly capable.
Where pwa.gripe cherry-picks and has an axe to grind, pwascore.com is intended to be a more thorough and dispassionate evaluation. I will add desktop browsers soon.
Click "Expand All" for a complete and detailed list. Click "How Scores Work" to understand the scoring heuristics.
Well the notifications on your web site doesn't provide the full idea of how limited it is in Safari. We have to ask users to install the shortcut before allowing notifications with Safari. Guess how many users actually go through with installing the shortcut? Nearly none.
If we had to ask users to go into their settings and switch the "enable notifications" flag we wouldn't call that supporting anything. The whole process of installing a shortcut to even get to the point where we can ask for notifications is even more convoluted on iOS.
The most significant effect is that experimental and non-standard PWA capabilities aren't reflected in the primary score. You can see raw/unweighted scores by hovering over the primary score. Chrome wins handily if you count experimental/non-standard features.
For standards-based features I used a 4-tier model, described about halfway through the README (which I should also add to About):
This weighting turns out to be reasonably conservative. For example, if you hover over the score for Firefox (the largest benefactor), you'll see that it bumps Firefox's score by 5.
I'm very open to feedback. This is a sincere attempt to quantify vendors' PWA support.
It's a cool page, although somewhat limited in scope. If you want a more complete picture of all the web progress Apple is holding back, not "just" PWA and more advanced capabilities, this is probably a better site for comparison:
Did you try opening the page? Each feature says which spec it's part of (e.g. "W3C Draft", "W3C Candidate") with a link to it. It also shows which browser implemented a feature first. Often it's Chrome, but sometimes it's Firefox, Opera, or even desktop Safari!
Likewise, you can click on the Chrome icon to change comparison browser. Here's a list of features implemented in Firefox on Android but not in Safari on iOS (and therefore, not in Firefox on iOS either):
Fwiw, I've been a Firefox user for about 9 years. I would love to see Firefox be able to ship their engine on iOS. The main reason Firefox haven't implemented as many features as Chrome is that they lack the resources to. Anti-competitive behaviour has hurt them a lot, and being forced to use a sub-par, undifferentiated browser engine on iOS - the world's most valuable and influential OS, has played a big part in this.
First of all, features can be a standard without (full) FF and/or Safari support.
Second, Safari has a monopoly on iOS and controls what other browsers can support on the platform (that also usually means "less than Safari", because SF gets to support things first). They are in a unique position to hold back the entire web, even on other platforms. They're holding the standards hostage by not allowing the market to decide which features are important to them (and put pressure on Safari and FF to implement them)
> First of all, features can be a standard without (full) FF and/or Safari support.
No. No they can't. A feature that is shipped in a single browser is just that: that browser's non-interoperable feature.
We literally lived through this with Internet Explorer.
The only reason the web is thriving now is because browser vendors agreed not to push this shit any longer. Well, until Google decided that whatever it does is the web, and until people who are not even paid by Google started unironically pushing the idea of "whatever Google spits out is the essential web standard now".
I mean, the status of multiple APIs on any of those "Safari is bad PWA is good" sites are literally in the "it's a napkin scribble, not on any standards track".
> They're holding the standards hostage by not allowing the market to decide which features are important to them (and put pressure on Safari and FF to implement them)
Who puts the pressure on FF to not implement Chrome-only non-standard APIs? Even desktop Firefox doesn't want to touch that pile of garbage with a 10-yard stick. And yeah, let's not pretend that Chrome somehow got to where it is by "market deciding".
> A feature that is shipped in a single browser is just that: that browser's non-interoperable feature.
AFAIK, the popover and/or anchor positioning APIs was standards before it shipped in more than one browser. (I will say that all three(?) of them agreed to build it)
> "it's a napkin scribble, not on any standards track".
Chromium/Blink have a process, and it's quite rigorous (precisely because they understand that they're pushing things, so they have a responsibility to make sure it's good):
> I will say that all three(?) of them agreed to build it
This is the key sentence
> Chromium/Blink have a process, and it's quite rigorous
It's Chrome's process, and Chrome's deadlines.
> they have a responsibility to make sure it's good)
Strange then that they routinely don't wait for and ignore any and all input from other browser vendors and ship their own APIs without any consensus or agreement because "their rigorous process is good" or something.
E.g. almost every single API marked as "experimental" on MDN docs [1] is already shipped in Chrome despite most specs being "not on any standards track", "has multiple issues", "no consensus and API is in flux" or "it is provided for discussion only and may change at any moment."
Hi! Creator here (of iOS404) - you can filter level of standard and compare to FF Android (or compare to Safari Desktop, or any mix) instead if you'd like.
It's called iOS404, not "FF" or "Chrome" and pushes the narrative that iOS is bad, and missing features.
There are 34 features listed (IIRC it did contain a bunch of Chrome-only crap once upon the time, hence my harsh reaction). All of them enabled by default. If we limit this only to actual, you know, standards, and not "scribbled on a napkin, awaits review", we get a grand total of 9 (yes, nine). And even there many are not "not implemented" but "missing some features (sometimes big, sometimes small and irrelevant)".
Are you mad because they probably found the same thing I did when doing web stuff that had to run on iOS (going as far back as about 2012~) that iOS required so much more hoop jumping, hacks, polyfills etc? It was just assumed that every other platform worked fine, time was always allocated for inevitable issues on mobile Safari.
Yep - the site has a point of view but rooted in real data that you can filter as you'd like.
I've had real-world experiences where I develop something that works on my Mac and my Pixel phone but cannot work on iOS WebKit (basically kaputt on iPhones). It inspired the creation of the site - specifically not being able to allow users to have Audio at anything but 100% seemed extremely weird.
I'm not offended by sites that also point out issues with a slant against Google. Ie: killedbygoogle - I think these things are great, fun, and interesting.
Google has become the developer-focused company that Microsoft used to be, and I don’t mean that positively. Developers are lazy and want to inflict low-effort crap on users. Microsoft always made it easier to do that. Google is now doing the same thing. Offering developers more and more ways to cobble together box-checking functionality in web apps instead of developing proper native apps.
Author here. I have no affiliation with Chrome, and use Zen and Firefox Mobile pretty much exclusively. I recently made an ESP32 hardware side project that I can configure entirely in the web browser via Web Bluetooth, got hyped, then immediately sad that my page was never going to work on iOS / iPad OS. So I threw together this webpage from caniuse.com data.
No average person cares about your side project, and most people prefer Apple’s product decisions over the ones you’d like them to make. Based on your history with technology, you are a Windows developer who would like to distribute apps on Apple’s platform without learning about what makes for a great app on that platform.
People like you could turn off these features and continue installing and updating native binaries for the Starbucks app or random hardware companion apps all you want. I'd like first-class PWAs please.
When the obvious answer I gave about how to reduce the memory footprint and make it more performant was “to stop using fucking [web technologies]” and create a native app
But the question I always ask people who say that it’s mean old Apple keeping PWAs back, why is it that all of these same companies see a need to create an app for Android?
To your last point surely it makes sense that they'd probably be rolling something like RN or similar where at that point they may as well build for Android app as well right?
Versus with proper PWA support across the board, a single button on the company's site that installs a PWA no matter which platform your customers are on.
Papa John’s doesn’t need a website seemingly and everything you can do on the app you can do on the website. Why is the app so much faster? I can say the same for banking apps, Airbnb, hotel apps, etc
There must be some reason that every major company decided to have an app even though today all of the same functionality is available on the web.
I argue that developers enable the egregious behaviour by supporting safari in the first place. Just as IE was called out and shunned for its shenanigans, before they started behaving better, so too does safari need to be treated. However, it does also feel too late, they have crippled other browsers too with their platform abuse masquerading as requirements while we celebrated it.
Is it really egregious that Apple doesn’t support everything Google decides to push? Most of these are features I don’t care about, or in some cases actively do not want.
I’m also not sure how accurate this page is. They claim Chrome on Android supports registerProtocolHandler while MDN says it’s not supported there.
Yeah, I don't want background sync. I mean, iOS is built upon the idea that any task in the background might be killed at any time and without warning by the OS. This is so the OS is able to manage battery and memory effective.
You can of course dislike this, but not even native apps allow background sync anyway, so of course web apps would not be allowed to do this either.
I left after seeing Contact Picker API listed. Contact Picker API is, per the MDN link in the OP, marked as "This is an experimental technology." It is "not Baseline because it does not work in some of the most widely-used browsers."
This is the current choice developers face - build for the app-store or build for the web. Or both.
For me, I honestly don't care if Mobile Safari seems 'crippled' when everything I use works exactly the same on devices as on Firefox/Desktop. If anything I'd be more annoyed if it worked better on my fringe devices, but maybe I'm the outlier here - I only use mobile for comms/banking, tablet for light browsing, and it's more often I'll be on Desktop.
Do I think it should have less functionality in Mobile Safari - yes if I get more battery life. Conversely no, if those features could give me more battery life back through intelligent apps.
For those of you who believe support for PWAs is critically important: in what way does it impact you? What kind of solution are you providing (or, put another way, what problem are you solving) for customers, and why would a PWA app be better than a native one for them? (As opposed to, say, convenience for you.)
Businesses tend to relay costs onto their customers (someone has to pay the bills).
- The app store tax
- The extra work of maintaining at least 2 separate apps (iOS, Android, optionally(?) desktop web app)
- Dealing with app store rules
Some of these are not just costs. I have experience with native apps that have to make things worse for users (compared to the web app) or risk getting booted off the app store.
I thought this was obvious, but higher costs for building and maintaining an app (vs a web app) means higher prices for users. I think people would love to pay less, and would hate to pay more.
What I’m looking for is an answer from you as it relates to your specific business, not speculation from an advocacy org that can gin up any hypothetical numbers they want.
I asked in the start of the thread: how does it impact you, or your customers?
If a web app doesn't work on iOS, a business builds a native app instead. iOS is too important. So that fantastic native-like PWA never gets built in the first place.
Apple is not just holding back PWA on iOS, they're holding back the entire web everywhere.
Compare that with desktop, where web apps (maybe not PWAs, strictly speaking) are dominating: Gmail, Office/Docs, GitHub, Figma, you basically do everything in web apps.
And if you count Electron [1]: VSCode, Slack, Spotify, etc, etc.
[1] Importantly, Electron lets you bring your own (browser) engine. You can build a native app on iOS that is just a wrapper around a web app, but it has to run on iOS' WebKit, and is thus limited by what Apple deems worthy
First of all: don't they? (honest question, I truly don't know if Africa has more PWAs compared to US/EU/etc)
Second: There are many reasons why businesses would opt for a native app. Notifications, for one (not available on the web on iOS until just a couple of years ago). Also, native apps allow for more tracking (whereas browsers are paranoid by default).
Third: A few years back, companies like FB, Google and Twitter all launched "Lite" versions of their apps, specifically targeted at Africa and other developing markets. They were all web apps (or wrappers around web apps). I will admit that this was years ago, and I have not checked if these Lite versions are still around and/or widely used.
> If a web app doesn't work on iOS, a business builds a native app instead. iOS is too important. So that fantastic native-like PWA never gets built in the first place.
So, instead of hiring a team to build an amazing PWA for Android, and an app for iOS, business hires three teams? One building a web app, a native app for iOS, and a native app for Android?
> Compare that with desktop, where web apps (maybe not PWAs, strictly speaking)
Indeed, these are not PWAs, not even strictly speaking. Also, they all depend on full desktop browser to work (often due to sheer fact that they are complex apps that don't work well on mobile screens), and none of them including Google have an amazing native-like PWA experience on Android.
I mean, you're bemoaning iOS crippling PWAs on iOS. It should be so easy to show amazing non-crippled PWAs on Android. After all, we've been told for the better part of the decade that PWAs are amazing native-like now. Android's market share is 68-70% worldwide. You'd think someone would finally be able to show the full power of a PWA? Anyone?
> And if you count Electron [1]: VSCode, Slack, Spotify, etc, etc.
One of them has millions of man-hours and millions of dollars of investment to make it somewhat performant. The others struggle to show a few pages of text and images in less than 1GB or RAM. Not the flex you think it is.
Yes. The web's winning feature is "it works everywhere". If your app doesn't work for the wealthiest 50% of users, why go that route? Making a desktop web app work on mobile, just for Android, is a lot of work. It needs to work on both iOS and Android to make it worthwhile.
> they all depend on full desktop browser to work (often due to sheer fact that they are complex apps that don't work well on mobile screens)
Gmail, Office, Docs - they all exist on mobile (as native apps). So it's not the complexity itself that makes it a problem on mobile screens. What does the native Gmail app do that the desktop web app doesn't?
> Android's market share is 68-70% worldwide.
Not in the wealthiest parts of the world, where the money is.
> If your app doesn't work for the wealthiest 50% of users, why go that route?
Why doesn't business hire two teams? One for the amazing native-like PWA, and one for iOS?
> Making a desktop web app work on mobile, just for Android, is a lot of work.
More work than hiring a separate Android team? More work than hiring a team to create a PWA which we've heard continuously for the past 10 years is amazingly easy and native-like?
> Gmail, Office, Docs - they all exist on mobile (as native apps). S
Yes, yes they do. As native apps
> Not in the wealthiest parts of the world, where the money is.
In 10 years you'd think we'd see actual examples of these amazing fast native-like PWAs on Android. All we hear is excuses.
Funnily enough I know of a few. E.g. Foodora's web app is surprisingly good, and it's possible that their "native" app is just running inside a webview, since it's indistibguishable from their website. But even MORE funnily enough, it takes a PWA sceptic to spot good PWA apps when none of the PWA proponents can point to a good PWA to save their life.
How many of these features that chrome offers have been fully flushed out and in a true working stable state? Google Chrome has a habit of pushing features out before they're really ready and Safari is usually on par with Firefox for features from what I have seen.
It's not a question of readiness or capability. It's an MBA with a spreadsheet explaining to a room full of people how much money Apple will lose if they allow X feature to work in Safari. This is user-negative behavior from a company that has so much money the best thing they can think of to do with it is to bank it offshore in a tax haven.
Conversly, there is an MBA at google saying how much money they can make for each extra piece of data they can extract off the user’s phone.
I agree an open web platform is good. But i also think some of the things added to the browser don’t belong in the browser. Face detection? i don’t need that.
I am much more partial to attempts to force apple to enable installing 3rd party apps than i am forcing them to bloat the browser with more ways for websites to monitize me.
I’ll ask the dual question: how many of the mobile safari checkmarks are fully fleshed out? Media Session has a check, but I have absolutely fought obvious Media Session implementation bugs in my own PWAs when designing for mobile safari
This isn't about browsers, it's about Apple spending the last decade blocking PWAs on their platform by intentionally breaking something new with every new OS release, thus forcing people to build and ship bloated pointless 50meg webview packages through their aPp StOrE every time they update the width of their sidebar.
PWAs are great. They were literally Steve Jobs' original vision for the iPhone. I don't know why people are arguing about Firefox or the individual features - that's not the point, they're not the ones that matter. It's the decade of sabotage.
Yes. Here's a quote for you from the original WWDC 2007 iPhone launch[0]: _"We've come up with a very sweet solution. An innovative new way to create applications... it’s all based on the fact that we have the full Safari engine in the iPhone. And so you can write amazing Web 2.0 and Ajax apps that look exactly and behave exactly like apps on the iPhone! And guess what? There’s no SDK that you need!"_
> I think one of IOSs strength is its operating system
one of the OS' strengths is its OS, cool
> and proper native apps
not what we're talking about here at all
> PWAs are inaccessible, bloated, slow and awkward to use.
It's an interesting way to go about it. But I am not sure it's the same as what we get now. We aren't just leveraging the webkit renderer, we are using the browser as a complete OS/runtime for your applications. On top of an OS that already has its own UI libraries.
The current standard is that when you visit a webpage you are downloading an application in the tens of megabytes. In 2007 that would barely be possible.
When I think of PWAs I think of Microsoft Teams. It's slow as a website and somehow slower as a >100mb "native" app.
Anyway thanks for the reference. I am curious how much the current method strays from what Apple envisioned back then.
Native apps were never a part of the original iPhone release, all the apps were essentially web apps, running one at a time (no multi-tasking/running in background unlike it being built into Android from the get-go).
I'm not sure the other commenters claiming all these features are attack vectors actually read the list?
How is the barcode detection API a security risk for example? Having it implemented would be amazing for web apps.
Also there's features like deep linking into PWAs that ought to be pretty basic PWA functionality that's not on this list that even Safari on Mac OSX has but Safari on iOS doesn't. Even the add to home screen menu option is deliberately made hard to find.
Apple doing this for the benefit of the user is one of the less likely hypotheses.
Google never really cared about Chrome on iOS. They barely care about Chrome on Android to be honest, that app still looks and feels more or less the same it did 10 years ago.
Yes, they can't bring their own engine, but it's in their interest to lock users in and ensure they continue using Chrome on iOS. But it took them years to implement available APIs like passwords (AFAIR it was out for 3-4 years before they allowed Chrome iOS to supply your passwords).
This table could stand to have a desktop safari column. For instance folliwing the "shortcuts" link https://developer.mozilla.org/en-US/docs/Web/Progressive_web... says "safari: yes (17.4), mobile safari: no".
So it's not like Apple is fully against at least some of these APIs.
it doesn't eat into AppStore sales to support it on mac because most use non appstore apps anyways. on iOS, PWAs are the one alternative to apps that Apple can take a sales cut from, which makes them a threat to their services revenue
As a daily Safari on iOS user, I don’t care about any of this, but since iOS 26 basic Safari features such as bookmarks and text search have become so buried deep underneath, they are basically unusable at this point.
It infuriates me a lot more than all the liquid glass stuff (on which I’m neutral overall).
I had to double check i’m running ios 26 because none of those things have moved for me recently.
Search is where it always was (type in the search bar, scroll past the google results to the in-page results) and bookmarking is also where it’s always been (share button “add bookmark”)
Damn. I never knew that way to search things. I used to do « Share / Search on this page » which was already obnoxious, which has now become « … » / « Share » / « Search on this page ».
Either I’m dumb or there is a discoverability problem with all these features. Probably a bit of both.
If you go to settings > apps > safari, and scroll to the “tabs” secttion, then turn off “compact” you get rid of the “…” button and go back to what it used to look like before.
Which is why i didn’t notice the change, as i had already set this setting to put the url back at the top an update or two ago.
A friend was telling me yesterday that this is how you can set custom ringtones on iOS. He seemed really excited about it, how cute.
Because I literally could not believe the archaic process previously used until very recently to set a ringtone on iOS. And now it's under the share menu?! Why do Apple people put up with this shit?
I've been able to set a custom ringtone in Android from the OS settings/any file browser app for at least 15 years and I would not be surprised if Android launched with it.
>Apple still sells 30-second song ringtones for $1.29 each through the iTunes Store app.
It’s been there since literally iPhoneOS 1.0. They are calling it “share” now, but really it’s always meant “put / send this somewhere”. The difference with recent versions of iOS is that the share button is no longer always visible but you need to press the ellipses button to reveal it. It’s there along with all the other dastardly actions Apple doesn’t want you to know about, such as “Add to Favourites”.
To be honest, I'm really surprised they let PWAs have notifications. That's literally the only use case we have on that entire page and it actually works.
I want location permissions for web apps installed to the home screen to be separate from Safari.
I want to auto-deny websites asking me for location permissions. But I want to be able to grant location permissions to installed web apps on a case-by-case basis just like with regular apps.
Used to have Firefox as a content filter for Safari on iOS (adblocking), but have since switched to Brave. It's a great option if you ignore all the crypto spam.
hey the AR/VR entry is wrong, right? Apple demonstrates it in the keynote webpages by having a 3D model relating to the keynotes' themes that can be placed and rotated in space, I doubt it would be for their own pages only.
unless it means having the webpage itself render in VR and not just an isolated model
yeah I'm using mobile Firefox and it has an awfully high overlap with Safari. Almost like a bunch of the stuff Chrome supports isn't actually a standard at all yet...
For me, the biggest hurdle to writing a PWA is the insane installation process [1]. There are also a ton of quirks, eg I don’t think you can update the icon if it’s installed as a PWA. It is hard to argue that this whole process has not been hobbled intentionally.
I recently posted about how I refuse to buy apple products because of stuff like this. The lock in has made iPhone users dependent on a app ecosystem when we could have had most of our functionality through the open web.
People saying they don't want these features are missing the point. Its about control and if developers have the option to make something as a website that actually works that gives them less incentive to make an app that apple can take 30% of your profit from while you are forced to write in their proprietary language for the stuff that only works on their devices.
So much engineering duplication of effort and waste just to satisfy a bottom line.
The web can be a competitor for the app stores, breaking that monopoly. It already did on desktop (where most users spend > 90% of their time in a browser)
And yes, you can write native apps in a lot of languages, but you can't choose how/where you distribute.
Except one of the main things i like about the web is that websites don’t have invasive access to my life. The web-as-app-platform idea erodes that.
But either way the issue is the same - apple preventing us from installing what we want. But my solution protects freedom in a more robust way: if you break the app store monopoly, you can install chrome or firefox and do all the web-app-platform nonsense you want. If safari adds all the features on that list you’re still stuck demanding apple add a new feature every time you want to innovate.
And as for programming - for the web you can write in a lot of languages but you only have two options For debugging - js and webassembly.
> if you break the app store monopoly, you can install chrome or firefox and do all the web-app-platform nonsense you want
Apple would also need to be forced to provide the APIs that browsers need so they can properly integrate with the OS (a lot of those APIs are private, currently), but good point, that would absolutely be one way to break this open.
“Private api” is fairly meaningless outside of an app store context. The symbols are easily extracted and headers can be re-constructed in minutes. The issue has always been that if you use these apis your app will be rejected from the store.
I very much appreciate the secure baseline Safari settles on. The entire ecosystem is protected by Safari being slow and reasonable.
My only peeve is that Apple resets the feature flags with every update. So the one experimental feature I use I have to reenable each and every time I get a phone update.
I would gladly give up all those “features” to use Safari over Chrome on Android. I don’t even know what kind of dumbass on Hacker News voluntarily raw dogs the internet on Chrome Android. Pathetic that Safari has had extension support for multiple years now while Chrome is still ass.
Absolutely nothing listed on that site as unsupported by Safari has any business being part of the web. In fact several supported APIs should be chucked too. Fuck giving websites motion data or push notifications.
I don’t care what your website does, not one tiny bit. I care that the majority of websites are shit, and therefore the web platform should be as minimal and isoltated from the device as possible.
Some people feel just as passionate about OS-level notifications and location permissions, and they turn them off. You can turn them off in your browser's settings as well. You'll be okay.
These are not features of functional websites, these are features that make every website an "app" and deprecate the idea of a traditional website. Google is embrace, extend, extinguishing the web as we know it. If Apple gives in, it's over, every website will just be an app and want access to your contacts, and your family history, and whether or not you are on Santa's naughty list or whatever.
Better PWA support gives users (and developers) more optionality with app distribution. Apple building out these APIs would not take away from their native apps.
The UX of visiting a site and with a single click of a button having an app on my home screen sounds great. I'd also like to have the option of side loading a native app too. And if those options sound unappealing, you can keep using the App Store if you want the assurance of using an 'officially approved' app.
A lot of very prominent apps are written using web technologies anyways. Take a look at the continued popularity of React Native (and Flutter as well).
> A lot of very prominent apps are written using web technologies anyways. Take a look at the continued popularity of React Native (and Flutter as well).
And it shows through their laggy interfaces and non-native UI/UX. The people don't like apps built with web tech; developers and LLMs like them because they're a shortcut.
Funny you would say that. Because businesses and users have only one choice on iOS: native apps, because the web app isn't viable (and/or available) on iOS.
I am curious why Safari in particular is getting a lot of the hate here when firefox supports even less of the features which leads me to believe that the reason many of these features have not been accepted is because they have not been accepted by the larger ecosystem and is just google pushing their own things as standard (Feels like IE days in many ways).
That being said, I am not sure why I would actually want most of these features in the browser? Many of these things feel like they further complicate what a browser is supposed to be doing and opens up security concerns at the same time.
I think the idea of using a web app for many tasks instead of apps is fine, but I don't think the idea that a web app can do everything is the way to go.
Edit: To be clear about the Firefox comment, notice that many of the features that are not supported non chromium browsers don't support on any platform. So the question on whether these are considered web standards is outside of whether iOS allows other engines.
Edit again: Apparently the third column is based on your current browser instead of always comparing chrome, mobile safari, and firefox like I assumed. I am currently on Firefox on Windows, and there are more red X's under Firefox for me. Seems like a weird choice to not always compare all major browsers.
Firefox is not in a position where it is the only browser allowed to run on a platform.
On iOS, you’re either doing a native app, sharing 30% of your income with Apple, or you’re restricted to Safari’s feature set. No browser in iOS can use anything but WebKit
It came out in the Epic trial that 90% of App Store revenue comes from loot boxes and other pay to win game mechanics - cry my a river for those companies.
The other companies that are making money from mobile are usually front end for services that don’t monetize directly through in app purchases or give you the option of not paying through the App Store.
The first million in revenue is 15% not 30%
But also if it is just Apple, why do the same companies create apps for Android?
Let’s say in this world where there was an alternative browser engine that supported everything that you wanted, how much uptake do you think you would have for your app if someone had to download an alternate browser first?
Did I also mention that in the US at least you can link out to your own payment system?
Also let’s not forget that Google’s app store fees are also 30%
Even so, conflating "Safari is holding the web platform back by not implementing standardized web features" with "Safari is holding the Google platform back by not implementing non-standard Google features" is kind of disingenuous.
Going through some of the list from the top:
* Shortcuts in the manifest: This seems to be standard. Would be nice if mobile Safari supported it.
* Protocol Handling: This is non-standard.
* File Handling: MDN doesn't contain a reference to a standard, and it has this caveat: "At present this feature is only available on Chromium-based browsers, and only on desktop operating systems". So not only does it seem to be non-standard; Chrome on Android doesn't even support it!
* Contact Picker: This seems to be moving through the standardization process and is not yet standardized, if I understand MDN's "experimental" label correctly.
* Face Detection: This seems to be yet another not-yet-standard API.
* Vibration: This is standard, it's a shame Safari doesn't implement it.
I'll stop here but you get the point. 2/6 are actual standards; 4/6 are just features Chromium implemented even though they aren't standard.
I'm glad mobile Safari doesn't follow every Google whim. Google has enough power over the standardization process as it is; we don't want them to control which features browsers add outside of the standard too.
In addition, parts of the list seems to be extremely outdated: Safari on iOS does support the Web Push API and most of the Notifications API (at least for apps added to your home screen as PWAs). These APIs have been supported since iOS 16.4, according to MDN.
> Vibration: This is standard, it's a shame Safari doesn't implement it.
I would rather prefer web pages do not gain the ability to make my phone vibrate.
>Even so, conflating "Safari is holding the web platform back by not implementing standardized web features" with "Safari is holding the Google platform back by not implementing non-standard Google features" is kind of disingenuous.
You missed the point completely.
Apple >forbids< any browser engine on iOS other than their own Safari. So you can't just install Chrome on iOS, because when you do you get Safari instead.
I would not care how Apple cripples their own web browser if they didn't force other browsers on iOS to use their browser engine. They are forcing me to write a native app instead of just tell my customers to install Chrome to have access to the APIs my product needs (web bluetooth).
I am not an iOS app developer, I'm a web developer. I don't have the resources to support that kind of code when I already have a perfectly working web app on the competing platform. I also do not plan to sell anything through my webapp, which is why Apple wants to force developers to create a native app, where they can collect 30% (or whatever % it is now) of anything sold through the app.
It doesn't matter what the standards are or aren't. Apple are just being greedy assholes and what they are doing is absolutely worse than what Microsoft did to get sued in an antitrust case when they simply bundled IE in Windows.
And to make it worse, Apple is on the board that decides what standards get into W3C, so they are blocking useful APIs based on their own greed.
This is part of the reason Apple is currently being sued by the DOJ
https://www.justice.gov/archives/opa/media/1344546/dl?inline
Mobile safari is arguably the only thing standing between Google and total browser dominance. It's the reason why Google "only" has roughly 75% of the mobile browser market even though it has a 90% market share in desktop. I'm principally against the idea that Apple can prevent users from installing the software they want on their own devices, but we can't deny that it's better for the health of the web.
Anyway, if you want to exclusively argue "Users should be able to install the browser they want", that's fine. But you're not; both your comment and the pwa.gripe page brings up how Apple is "crippling" their own web browser. Since you use the same wording as pwa.gripe, I assume you too view the lack of non-standard Google-only features as "crippling mobile Safari". I disagree.
> Mobile safari is arguably the only thing standing between Google and total browser dominance
"Apple Is Not Defending Browser Engine Choice"
https://infrequently.org/2022/06/apple-is-not-defending-brow...
You seem to be conflating my opinion of "iOS's lack of browser choice has the consequence of preventing Chromium from achieving total dominance" with some imaginary other person's opinion of "iOS's lack of browser choice is a benevolent act where good guy Apple valiantly defends the open web". I do, frankly, think that mobile Safari couldn't compete that well in an open market, just like desktop Firefox can't. (Not purely because Firefox is technically inferior, mind you; products don't compete purely on technical merit.)
I think Chromium out-competing every other browser engine is a bad thing.
Let Google dominate the web. If that’s a problem we can sort that out. But two wrongs don’t make a right.
As the ball of mud that is web standards grows, the less likely that it becomes that things can “sort themselves out”. Even as things are you need a literal army of developers to build and maintain a modern standards compliant browser, making any real threat to Chromium dominance unlikely, and that only intensifies as Google rolls ever more crap into the katamari. If users can then be harassed into switching to Chromium based browsers it’s likely that it will never be toppled short of some new technology superseding the web entirely.
If Google abusing it’s dominant position in web browsers is a problem then the solution is legislation and anti trust action. Letting Apple abuse its own position because it currently provides benefit is not a good approach.
Same thing played out with ads and tracking a few years ago, and now look at the ads situation in the App Store.
Do you remember Internet Explorer before Edge? Jeez I never want to go back to that. And that’s what we’d end up with in a browser monoculture.
Fix their dominant position through legislation, not with more monopolies and anticompetitive behavior.
Are you talking about Google or Apple? Because Apple is being sued by the DOJ for monopolistic and anticompetitive behavior. There are numerous examples of it spelled out in the lawsuit:
https://www.justice.gov/archives/opa/media/1344546/dl?inline
Both of them. To the extent that Google uses their position with chrome to give themselves in another domain they should be sued. Likewise, Apple refusing to allow consumers to install whatever applications they want on their own devices is so egregiously anticompetitive.
In their wildest of wet dreams Microsoft didn’t imagine they could get away with what Apple is getting away with.
> Let Google dominate the web
No thanks
Indeed, that would be a disaster.
https://en.wikipedia.org/wiki/Web_Environment_Integrity
Fix their dominant position through legislation, not with more monopolies and anticompetitive behavior.
I can do neither, actually. I can merely observe reality as it is and look at which forces affect the direction of the world. And right now, I observe a reality where one of the most significant forces which counteract a completely Chromium dominated web is Apple's user-hostile insistence on preventing browser engine competition on iOS.
I have very little faith in a legislative solution here since I believe politicians care about browsers, not browser engines. They see Chrome, Brave, Vivaldi, Edge and Opera and see a diverse marketplace with sufficient browser competition. They don't seem to care about the technical monoculture behind it all.
Apple doesn't even make Safari for the world's dominant platforms - Windows and Android, yet they continue to hold back progress in web browsers on all platforms to protect their own profit on their walled-garden platform.
They need to wrap up the DOJ lawsuit against Apple, but I fear the current administration will look the other way because "Tim Apple" gave the guy in charge a golden trophy. I wish I were joking.
> I think Chromium out-competing every other browser engine is a bad thing.
Hmm. I believe that Apple can compete with Google if they want to. They have the money, they have the marketing chops, they have the incentive ($20B search engine deal) and they are the default browser.
(also, they have trained iOS users that Safari is the only default browser on iOS for 14 yrs by not allowing other browsers to be set as the default)
All Apple has to do is actually compete, not just rely on their monopoly.
I mean, keeping one monopoly at bay (Chromium) with the other (WebKit requirement) isn't really how this is supposed to work, right?
> Hmm. I believe that Apple can compete with Google if they want to.
I don't think that would happen. I don't have much faith in Apple's abilities in this area, and their incentives are structured such that the less viable web apps are as a replacement to native apps, the more money they get from their 30% cut.
Again, your arguments would make sense if my opinion was: "good guy Apple valiantly defends the open web from Google out of the goodness of their hearts". But that isn't my argument. I don't care whether Apple could compete with Google if they tried. I care whether Apple would compete with Google, and they wouldn't.
> I mean, keeping one monopoly at bay (Chromium) with the other (WebKit requirement) isn't really how this is supposed to work, right?
WebKit isn't a browser monopoly, it has less than 20% of the browser market share. That 20% share is big enough to push web developers towards making websites work in browsers other than Chromium, but it's not big enough that there's a danger of web developers thinking, "everyone uses WebKit anyway so we won't bother testing on anything else".
Sure, it's a monopoly on iOS, but I don't see how this is relevant to my argument. The web is more important to me than iOS is.
> I care whether Apple would compete with Google, and they wouldn't.
They receive $20B a year from Google (search engine deal). Some estimates put WebKit/Safari's budget at $500M. That's a rounding error away from $20B of pure profits. I completely agree that Apple is not in it for the good of the web. They are in it for $20B a year.
And even if they wouldn't want to compete: fine. Let them give up. Make room for browsers that do want to compete (or at least, let them try).
> WebKit isn't a browser monopoly, it has less than 20% of the browser market share.
That monopoly on iOS is enough, though. The web has to work on iOS because the wealthiest users have an iPhone, and all they have is WebKit. I work at a place where most of our users are on mobile, and most of them are on iOS. So WebKit sets the bar for what we can do. In other words, Apple is in full control of what we are able to do. Building features for Android users is often not worth our time and money, so we just don't build it.
> And even if they wouldn't want to compete: fine. Let them give up.
Again, this leads to Chromium out-competing everything else and getting as entrenched in mobile as it already is in desktop. This is a bad outcome.
> I work at a place where most of our users are on mobile, and most of them are on iOS. So WebKit sets the bar for what we can do.
In other words, Apple has successfully prevented you from writing a web application which only works in Chromium. This is a good outcome.
> In other words, Apple has successfully prevented you from writing a web application
... by abusing their monopoly position on iOS (instead of competing).
Good outcome?
From the perspective of avoiding a web that's wholly controlled by Google? Yeah, absolutely.
Letting my users have access to the Web Bluetooth API is not making Google somehow take control of the web. If Apple won't implement it, and they won't allow other browsers on their platform, that's plainly an abusive business tactic. It's far worse than what Microsoft did by simply include IE with Windows - Microsoft never forced every browser application to use Internet Explorer. Can you imagine the outrage if they did??
But somehow Apple gets a pass, and you think they're somehow saving the web? Just stop.
Apple is stifling progress in favor of profit.
You're shadow boxing. I never said Apple isn't engaging in abusive business tactics. They clearly are. I just think the result benefits the open web by taking power away from Google.
And I pointed out that they don't help the open web, they stifle innovation of the web by abusing their power for profit.
Which I think is far worse than anything you think Google is trying to do.
I'm not giving Google a free pass here, sure they can be abusive, I hated "AMP" and I'm glad it got thrown on the junk pile. That was clearly abusive. But implementing Web Bluetooth? Not abusive, it's progress. And it's too bad Apple abuses their power and stifles progress in this case.
I can't say anything other than "I disagree"; I think it does help the open web. You already admitted that you in your day job has been forced to make your site work in non-Chromium browsers thanks to Apple's authoritarian stance. That's a purely good outcome in my book, as much as I dislike the lack of user freedom that's behind it.
>You already admitted that you in your day job has been forced to make your site work in non-Chromium browsers thanks to Apple's authoritarian stance.
I did not say that at all. I'm not supporting iOS at all for the features that Apple won't implement in Safari. Tough titties Apple users. And why should I? iOS and MacOS world-wide are a small percentage of all users. And Apple doesn't care what their users don't get to access, so long as Apple is making money.
Apple is not the good guy here.
They are actually doing the opposite of you want, not sure how you can't see that. "The web" is now essentially all Apple will allow it to be, for their own greedy reasons.
I don't think it does benefit the open web. If consumers can't get value from the web, they'll go where they can find it. That is currently native apps, which is a closed and proprietary ecosystem. This causes the market itself to shrink, which means fewer and fewer people will invest in the web [1].
Here's a good podcast episode with people from the Open Web Advocacy: https://changelog.com/jsparty/316
> I do, frankly, think that mobile Safari couldn't compete that well in an open market, just like desktop Firefox can't.
Couldn't compete isn't a justification to exploit platform control and ban competition. If Apple's so worried that Safari usage will fall off in favor of Chrome, then they can invest in Safari to make it a level playing field to keep their user base.
[1] https://infrequently.org/2023/02/the-market-for-lemons/
You clearly haven’t tried to design anything complicated that has to run on safari iOS. Safari iOS is a massive piece of shit. I’ve been working on a web game for a while now using canvas and most of my pain comes from making it compatible with safari. So much stuff is broken on safari so you have to find work arounds. Like a simple but annoying one, CSS filters don’t work on canvas so you have to write all those filters your self and apply them by using imgData.
Also the constant crashing when using canvas and the web audio api, it’s a disaster to be honest and it feels intentional, like they want me to write an app instead so they can rent seek.
As a non-web developer I'm interested if anyone can answer this question:
Answering with at least {Chromium,Safari,Firefox}Because if it's hard when targeting Chromium and adapting to {Safari,Firefox} but easy when targeting Safari and adapting to {Chromium,Firefox} then honestly it seems like Chromium is the problem.
What I want to distinguish is the biases in being used to programming in one environment and actual ease of programming for an arbitrary browser. Regardless of what official standards are, there are "in practice" standards, what is used in practice.
What would be nefarious is if Google is promoting people to program in ways that are not compatible with other browsers, cementing its monopoly. (This may even be achieved without explicit direction. Achievable simply by Chromium devs building tools for devs but not carrying about compatibility with other browsers). After all, the web is for everyone, but just because it's open doesn't mean monopolies/oligopolies/collusion/<other nefarious actions> can't happen.
Tdlr: does developing on chromium encourage browser incompatibility?
> Because if it's hard when targeting Chromium and adapting to {Safari,Firefox} but easy when targeting Safari and adapting to {Chromium,Firefox} then honestly it seems like Chromium is the problem.
Exactly. Test and develop against Firefox and/or Safari first and Chrome afterwards. If it’s not a true web standard and isn’t widely implemented, don’t use it.
The web worked fine for decades without smart fridge integration or whatever weird thing Google has decided that browsers must be capable of most recently.
It's not easy, though. Most of my day job is spent trying to get html interactives on an e-learning platform to work reliably with iOS's ridiculous nonstandard interaction rules around when media is allowed to play. It's worse than working with the 20 year old jsp+servlet system that serves the interactives and business logic. no other browser behaves like iOS safari and to debug and develop against it you need an ios and macos device sitting on your desk. Firefox and Firefox on Android are a breeze but a rounding-error in our usage metrics, even accounting for our development. Apple desparately hobbles the web platform to collect IAP taxes.
> with iOS's ridiculous nonstandard interaction rules around when media is allowed to play.
Are there any standard interaction rules on when media is allowed to play? I thought everyone implements it differently based on their own ideas of security and user engagement
The problem is not Google, I hate Google so I’m not white knighting them or anything but a lot of basic things are just badly implemented on iOS safari. Also if something works in chrome it probably works in Firefox as well. The only odd duck is safari and people who defend clearly have no experience trying to develop for it.
Making things work in chrome and Firefox is trivial and is never hard but when it comes to safari you have to figure out the special dance to make things work properly even when targeting it first.
No developing for chrome does not encourage browser incompatibility.
Odd, because I hear so much about Firefox breaking. I'm a daily user so I don't know what they're talking about but still
The argument which has been provided so far about why Safari is crippled is that it does not implement non-standard Chromium-only features. There are other problems with Safari, but they are not found in the page we are discussing.
I compiled a "short" list of why amd how Safari is crippled. Not entirely on topic for the post, but seems appropriate as a reply on this particular comment ;)
https://webventures.rejh.nl/blog/2024/history-of-safari-show...
This article is quite literally the only one that actually discusses actual Safari problems.
And even this article falls prey to "failures in web platform tests" which are a very poor indicator. E.g. Safari passing all accessibility tests is much more important than Safari failing most accelerometer tests that only Chrome passes (because this is Chrome-only API).
This is excellent!
Seeing that there are cross platform game engines, it seems to me that making a web game is not the best way to go. How do you plan to monetize it? Get people to put their credit card on your website? How is your web game performing on Android? Have you tested the performance on the typical mid range Android phone?
Why isn’t it the best way to go? I’m not a fan of those web game engines so I made my own.
I have various avenues of monitization; sponsored ads and letting players buy cosmetic items.
I have yet to test it on android because my priorities are making it work on desktop and iOS first and then android after. Why? because of my past experiences with making games.
Monetization? But does making your own engine “make the beer taste better”? Does it lead to a better experience for the users? Does it give you an advantage in the market?
You really don’t think you need to consider the hardware capabilities of the average Android phone?
Hint: Facebook rewrite their apps years ago to not use web based technology because performance was horrible on the average Android phone.
Yes it does because it’s optimized and efficient because there is no bloat, everything in the engine is there to serve this specific game.
I will eventually test it on android but I don’t see why it would not work with out any issues.
I wouldn’t use Facebook as a reference, I have an inside joke that they have the worst programmers. They managed to make a site that shows text and images make my computers fans spin which is honestly just embarrassing all things considered.
You really don’t see how inefficient it is running a game on a web browser compared to a game engine running native code for the platform? And you think you are going to write a better performing game engine in a web browser?
> Yes it does because it’s optimized and efficient because there is no bloat, everything in the engine is there to serve this specific game.
Everything is there to serve your game except the entire web browser.
I don’t know what you’re on about, my game runs at 60fps while using 10% of the cpu and some GPU.
As an iOS user, I’m quite happy you have to jump through these hoops instead of being able to force me to use a Google product.
You can still build a PWA and get most of the benefits (I use a few PWAs on my iPhone daily). Or you can package it through Expo and rely on the Reader app exception without letting users sign up on iOS (although the rules around that are changing and you might be able to).
I get the gist of the article but what specific features do you need to let people just use your app as a PWA on iOS? Do you need access to the NFC, for instance?
I need web bluetooth to give users the full experience. They can use most of my platform currently on Safari, but not the really cool stuff that web bluetooth enables.
> They are forcing me to write a native app instead of just tell my customers to install Chrome to have access to the APIs my product needs (web bluetooth).
Why don’t you encourage them to get an Android? What makes you think that people who prefer an iOS device over Android would even install Chrome after you nag them with dark patterns?
> I also do not plan to sell anything through my webapp, which is why Apple wants to force developers to create a native app, where they can collect 30% (or whatever % it is now) of anything sold through the app.
Sorry, not following you: Apple is forcing you to give them 30% of nothing? How exactly is that a problem?
> Apple are just being greedy assholes and what they are doing is absolutely worse than what Microsoft did to get sued in an antitrust case when they simply bundled IE in Windows.
Yes, how dare Apple look after their [checks notes] customers by preventing devs from using the features that would most annoy their customers?!? Such a greedy thing for a company to do, to give customers what they want! The only true purpose of a company ought to make it easy to slurp up customer data and monetize eyeballs!
> What makes you think that people who prefer an iOS device over Android would even install Firefox
100% guaranteed people would. I know this for a fact. You somehow have proof of the negative for some reason. Maybe you can share that.
Regardless, just because you are satisfied with iOS as a platform doesn't mean others don't continue to wish for improvements.
Can I ask which version of iOS was perfect in our mind?
What fact? Have you checked Firefox's market share even on desktop?
That people would use Firefox on iOS. That fact. Do you know English? It seems like you understood what I said, but still had a hard time comprehending it. Are you okay?
> Can I ask which version of iOS was perfect in our mind?
6.
Guess what? You not having the resources to have anything but a shitty PWA is not my problem.
Do you really think that you are going to get any level of monetization by forcing users to first download a hypothetical web browser that has all of the features you want? That web browser doesn’t exist on any mobile platform
You have no idea what my web application is, or whether it is shitty or not. So thanks for the troll - it reminds of my days on reddit, but now this pointless internet interaction is over.
A web app has never in history been as performant as a native app.
Not everything needs to be at the highest high of "performant", and you're ridiculous to use that as a gotcha.
I told you, this pointless internet interaction is over. You are not here to argue in good faith, so take it somewhere else.
So yet another shitty bloated web app…
this pointless internet interaction is over
> No browser in iOS can use anything but WebKit
Your statement is true only outside of EU countries.
Is any popular browser actually available with non-WebKit browser in EU? So far I wasn't able to confirm this.
No it's not. The percentage of people who actually can use alt stores is so small that nobody will really dedicate money to make browser build for iOS. Why would they when Apple would just make the work impossible anyway.
It's pure malicious compliance from Apple. Anybody defending Apple on this is simply delusional.
Alt stores and web engine stuff are two separate things: https://developer.apple.com/support/alternative-browser-engi...
Browsers with alternative engines can be offered in regular AppStore. That's why I wonder why isn't this a thing. At the end of the day, browser makers probably want to reduce confusion and complexity of maintaining two vastly different applications under the same name. This most likely isn't a case of malicious compliance, you got yourself carried away here I think.
I think malicious compliance is a fair interpretation of the situation: https://open-web-advocacy.org/blog/apples-browser-engine-ban...
I think the main technological limitation is that other browsers cannot just-in-time compile (JIT) JavaScript or any other embedded language. Except in the EU.
ETA: your link includes JIT; I’m pointing out that that’s why they don’t exist outside of the EU. Non-JIT browsers would just not be very performant.
If that is true, this is malicious complaint. Unless Safari has the same restrictions, of course.
This whole thing is of Apples doing. Of course they don't want to comply.
And regulators are obviously unwilling/unable to hit them with fines that really make a difference beyond "cost of doing business" small change.
Now it's straight up protectionism from USA. You touch our tech margins, we won't do business with you. So yeah the regulators are unable, even if they wanted to something.
Doctorow is right when he keeps saying that countries should make it legal to jailbreak devices. The problem is that first country that tries that will get hammer from the almighty POTUS.
The Chinese kicked out American companies when they were sure they could replace them with their own.
Keeping money in your own country and not funding the B2s that will bomb you one day.
Specifically due to regulations that Apple incited.
A significant amount of apps can get the 10% rule rather than 30%.
It doesn’t necessarily change the point in the end but it is worth noting.
> why I would actually want most of these features in the browser
The page is about PWAs, applications that can be installed by the browser rather than the platform's App Store. Native applications already have those capabilities and a lot more.
Because it’s essentially propaganda. By conflating “Not Implementing something Google did” with “Intentionally Crippling”, they hope to pressure Apple by through either the general public (the PR game) or through Government mandates (the lobbying game).
This has been going for at least as long as Blink was forked off WebKit.
And why Apple? Because Apple’s the only other browser giant, and they do have motivation to not implement a lot of these features. Frankly a lot of these are features I don’t want in my fucking browser either. But web developers, and businesses that predominantly rely on the web (such as Google) want as many complex APIs as possible implemented in the browser.
They don't need to implement it though. They just need to unban browser vendors from shipping their own engines.
Browser vendors have been able to ship their own engines in the EU for almost 2 years now. What great benefit to consumers has that enabled?
Some of Mozilla's positions are based on Apple's, such as the refusal to implement Web NFC [0].
Since Webkit has been the only engine allowed on iOS, ultimately this is a disagreement on app distribution. I can see Apple and Mozilla's argument regarding Web NFC, but I also don't want to write a whole app so my friends and I can play around with NFC tags. I find it irresistible to draw comparisons to the new Android situation regarding non-Play Store apps. If there was a developer registration list for websites (that was better than DNS registrar records and TLS certificates), would Apple and Mozilla find that acceptable? After all, I need to give my real name and payment details to Apple just to write an app.
But for good measure I will add one for Mozilla too. Firefox Android still doesn't support the Web Codecs API [1], so I need to use the "jpeg" codec on Selkies remote desktop sites, which I assume is rather poor for my bandwidth and battery.
[0] https://github.com/mozilla/standards-positions/issues/238 [1] https://caniuse.com/webcodecs
And chrome still does not support plugins on android, to my great surprise, while Safari has them on iOS. I honestly much rather have plugins than web nfc, or whatever the chrome bully decide should go in a browser.
Google’s choice to exclude extension support on Android can’t be a coincidence. Great example of conflict of interest with a web ad giant running a web browser.
It doesn't have to be an either/or situation and I certainly want both in my mobile browser!
Ad hominem is also not a valid argument against NFC. One of my friends built a whole automatic mahjong table with NFC tags. NFC apps are used in access control for offices, college dorms, apartment complexes. Businesses have obvious use cases for it, from inventory management to payments. Governments want to use NFC for government functions and visitor prearrival processing. Sure, maybe some of them want you to install apps for other reasons, but I can assure you not all of them do, so it's a shame that this function is so exclusive.
I think western users using NFC for payment, transit, gym access, etc. are not aware how apathetic the rest of the world would be if phones start taking out NFC, and one of the ultimate causes is that it's so difficult to work with across all users. It's just so much easier to make a website that shows a QR code that your PoS system or gym access gate can scan. Bottom of the barrel Android phones in India and China already ditched it and that's just going to exacerbate the issue. If it goes the way of the 3.5mm and microSD card in the next decade, we can put this in its autopsy report.
Firefox on iOS is just a wrapper around Safari, since that is all Apple allows.
The third column is your current browser and platform, and for me it's showing Firefox on macOS missing a lot of features. When I switch over to Brave, I see Chrome on macOS. Interestingly, Chrome on macOS apparently supports vibration, despite the hardware for it being nonexistent.
But on macOS you can switch to a browser that can do all these things. A company 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)
If you ask me to run a different browser, if at all possible I’m going to use a more reasonable competitor instead. I’m not about to return to the bad old days of sites badgering me to install IE because the dev thought it was a great idea to use ActiveX or whatever.
I'm not trying to defend Apple's decisions, I'm merely pointing out that the site is showing the feature support that Firefox has or doesn't have on macOS, or whatever other platform someone is using to access the site.
Fair :)
> the open webm
Sonehow you seem to confuse open web with Chrome-only non-standard APIs
No, because any browser can decide to ship a feature that it thinks is worthwhile. Users can decide which browser they trust to be their User Agent. The distribution model is open. You type a URL, you click a link. No single company in control.
> No, because any browser can decide to ship a feature that it thinks is worthwhile.
Yes, yes they can. They don't get to call it standard or essential. And Chrome-shilling sites like the pwa.gripe and a slew of others don't get to call those features "essential standards of the web".
> No single company in control.
That is literally not how standards work in the browser world by literal agreement of all browser vendors.
We literally lived through this with IE pushing its own non-standard features and calling it a day. Hence the whole "let's reach a consensus, and have several independent implementations of a feature before calling it a standard".
And if "no single company is in control", why then you're so enthusiastically pushing for a Google's full control of the web?
While true, that does not seem to align with what the checkboxes for firefox, looking at many of the ones that Safari does not support other non chromium browsers don't support on any OS. Mobile or not
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)
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?
>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
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
> 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...
> 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.
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.
> That's just your skewed take.
When you deliberately ignore what Google is doing, every view that is not praising Google's take over of the web is skewed.
> So what, bugs can be fixed.
No. Not on the web they can't. Once it's shipped, people depend on the functionality. That is why we're stuck with so many crappy unfixable APIs in the platform.
> Did people "boo" XMLHTTPRequest? Because it actually revolutionized the web, and people cheered it.
And yet, they didn't cheer ActiveX. For some reason you assume that every single API Google pushes out is XHR, and not ActiveX
>every view that is not praising Google's take over of the web is skewed
I am not praising Google. I'm simply pointing out that Apple is using abusive business tactics to prevent any competition. It's antitrust territory, and the DOJ agrees. I don't care which browser implements the APIs I need to access, so long as one of them does.
>No. Not on the web they can't. Once it's shipped, people depend on the functionality. That is why we're stuck with so many crappy unfixable APIs in the platform.
Just more skewed nonsense. This can and have been fixed on the web. I've had to reimplement countless APIs for all kinds of services. There are new APIs that make old ones deprecated all the time. Maybe you should try to keep up instead of stagnate like Apple is.
>And yet, they didn't cheer ActiveX. For some reason you assume that every single API Google pushes out is XHR, and not ActiveX
Just more bullshit from you. I'm tired of it. You aren't even attempting good faith arguments.
This pointless internet interaction is over.
> 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 :)
> I'm sorry, but that doesn't seem to be right. They have a process:
Yes, they do. It's their process, and their timelines. Many features on the page we're discussing are literally "drew on a napkin, not part of any standards process at all, shipped in Chrome"
>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.
> 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.
>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.
You continue to dwell on Bluetooth while ignoring that there are reasons to not just blindly follow Google which is what pages like this are advocating for. I honestly don't care about Bluetooth and I don't have any stakes on whether or not it is supported, and I also don't know enough about it to actually talk about security on it. I will leave that to people that actually know what they are talking about instead.
I would love if you can actually respond to Topics API and other initiatves that google has attempted that only furthers their agenda, just like you are saying Apple is doing. The fact is both companies are incentivized to do exactly that, and as I have already said both companies do this, and yet you seem to want to give Google a free pass and ignore when they have been problematic.
Regarding Firefox, them not implementing something is a very important piece of the puzzle and you cannot choose to ignore them just to try to strengthen your own argument. This is my fundamental issue with this page since they do not by default show Firefox because it completely breaks the "Apple Bad" narrative they are trying to push.
The fact is, Firefox on both mobile and desktop has not implemented many of the same API's that Safari has not and in some cases has implemented less. The Why there is extremely important because it directly impacts the conversation. Mozilla does not have any of the incentives that either Google has for pushing these features or that Apple has for not implementing them and yet they have chosen not to implement them.
>blindly follow Google
You obviously did not read my comment or understand it, so this pointless internet interaction is over.
> so this pointless internet interaction is over.
I do find it quite fascinating that you have written this phrase 5 times in this thread instead of actually being able to engage in a conversation you disagree with. Frankly it's not cute.
Sure it is pointless but you also chose to start engaging in the conversation since you were confident in what you wanted to say. Just as I am.
On multiple occasions you are purposefully ignoring what people are saying and attempting to just talk about something else. I have acknowledged your bluetooth comment but you refuse to acknowledge topics api or any other instance that Google has also used their power to try to do exactly what you claim Apple is doing.
Google is not your friend, neither is Apple. And you may not care what Mozilla does but W3C does so they matter and they don't have the incentives Apple does and yet they also chose not to implement many of the same features, which you also won't acknowledge.
I'm not wasting my time reading anything you write.
This pointless internet interaction is over.
Safari is a monopoly on iOS and iPadOS, that's a problem if you want to make a bleeding-edge PWA app, in that it's probably not going to work very well on iPad and iPhone and there is no web alternative on those platforms.
Firefox is entirely optional, not a monopoly anywhere.
The problem for me isn't making bad web browsers, it's enforcing those bad browsers as the only option on a computer platform.
KNOW THE BROWSER RULES
Firefox refusing to implement a web standard: APPROPRIATE
Safari refusing to implement a web standard: INAPPROPRIATE
Which browser engine are you getting on iOS when you install Firefox?
If you answered Firefox, you are WRONG.
You get Safari, because Apple forces all browsers on iOS to use their own crippled browser engine.
Apple also is part of the W3C board that gets to decide which APIs get to become standards, so they also influence what other browser makers do.
This would be a non-issue if Apple didn't force all browsers on iOS to use their Safari engine.
No, you get Firefox.
There is much more to a web browser than just its rendering engine. When you install Firefox on iOS, you get Firefox. It uses the WebKit rendering engine, but it’s still the Firefox browser.
To be frank, it’s pretty insulting and dismissive to all the people putting huge amounts of work into building browsers only to for you go around telling people that all their work is really just a mirage.
You didn't answer his question at all.
> Which browser engine?
There's no Firefox engine, there's Gecko engine. That's the core of Firefox' extension APIs.
Now, tell me how do you implement `webRequest.filterResponseData()` API for content blocker extension with WebKit: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
It absolutely is a mirage. It's like those Ferrari kit cars where you take a Ford or whatever car frame and remove the outer shell and put a Ferrari shell on top of it. It's not a Ferrari, it only looks like a Ferrari.
The browser engine is the majority part of the browser, everything else around it is window dressing. So when you install Firefox on iOS, you are getting Safari with a thin wrapper around it. You are not getting the Firefox rendering engine, which is the most important part of a web browser.
The problem is that it has to use the WebKit rendering engine, and not that it happens to.
I think it's more insulting to browser vendors that they have to throw away their browser engines to appease the monopolistic tendencies of one company.
You may wish to re-read the comment you respond to. To quote:
> Which browser engine are you getting on iOS when you install Firefox?
Emphasis mine.
You are a responding to a comment asking what browser engine you get, and the answer is Safari/Webkit.
> I am curious why Safari in particular is getting a lot of the hate here
Here is HN, where apple is the bad boy in town.
No this is where Apple gets handwaved with whataboutism.
Or maybe they deserve it?
The keyword is "intentional".
[dead]
I think anything that mentions Apple in a negative light gets reflexive upvotes.
I use both Apple and Android ecosystems, so I’ll occasionally participate in normal user conversations about features, how-tos, etc. Posting anything about the Android ecosystem, unless I was talking about Samsung features I disliked using, is no more or less likely to get down/upvoted than anything else I post about any other technology. Using any tone more positive than a negative-leaning neutral when referring to any Apple product reliably collects a handful of downvotes, and often a negative comment or two. Same thing with negative sentiment and upvotes. I’ve never seen such a passionate dislike of a corporation among a small number of people. Even with famous brand loyalty rivalries like Ford/Chevy in the 80s and 90s it was more mutual. It wasn’t like 99% of drivers not giving a shit, .5% of Ford users being smug, and 2% of GMC drivers just being super mad at a product they don’t own.
I don't think you're wrong, but what's especially interesting about this is that up until just a few years ago, it was completely the opposite. Giving any criticism of Apple would get so many rapid/reflexive downvotes that it often killed the comment before many people even got a change to see it. I experienced it myself a number of times. Having been reading HN now for ~13 years (I lurked for years before starting to participate), that's been my number one dislike about HN is the complete inability to have objective discussions about Apple. At one point I even wrote a quick browser extension to filter out posts that had Apple in the title because it was so nauseating. Ideally the pendulum wouldn't swing, but instead would just settle in the middle, but alas that just isn't human nature.
> Giving any criticism of Apple would get so many rapid/reflexive downvotes that it often killed the comment before many people even got a change to see it. I experienced it myself a number of times.
I’ve never found myself in any online community that meets that description. Certainly not HN, and HN hardly seems big enough to have Apple fanboy niches that you could accidentally find yourself in.
In the heyday of Steve Jobs’ Apple there was certainly a lot of praise here, but also constant prominent complaints about Apple being overpriced, or not open enough, or too litigious, or having too many fanboys.
I’ve seen way more complaints about Apple fanboyism than actual fanboyism. I’m genuinely curious how you could find yourself in one of those communities by accident.
Same. I have always found people talking about the hoards of rabid Apple fanboys but I’ve just never seen it in the wild. That’s even having been critical of Apple countless times over the years going back to the mid 90s even before Slashdot, let alone OS X. I’ve obviously seen the odd Apple fanatic out there but less frequently than , say, Linux evangelists or zealots for any given gaming platform over the past couple of decades or sports teams or cult band followers. Maybe in, like, the Apple subreddit? Brand subreddits are always where fanboys live for everything.
I think it’s a combination of underdog vibes and confirmation bias that people have adopted as a community identity.
It would be useful if the site listed whether these had been standardized outside of Chrome yet.
It’s hard to delineate which of these are Chrome features or actual web standards. And it’s therefore hard to blame either Safari or Firefox for not supporting them if they’re not standardized yet.
This is a huge list of "features from Chromium", which aren't really standard or even a thing outside of its ecosystem (the fact that both Firefox and Safari lack them is the obvious giveaway).
I'm happy that Firefox doesn't expose Bluetooth, NFC or similar stuff to websites: the browser is huge enough without needing to mediate even more access to local hardware.
It's unclear how some of these would even work for other Browser. E.g.: contacts. What data source would you use? I keep my contacts as vcard files in ~/contacts, but other folks might use a remove CalDAV server, a web-based GUI, or data stored in SQL which can be read by some other native client (I think KDE does this).
Agreed. I don't want websites to even request my NFC/Bluetooth/contacts.
Desktop Linux might not have a unified way of storing contacts but all other major operating systems do: Mac, Windows, Android, iOS.
So if your blocker to accept this feature is that it's "difficult to support on desktop Linux" then all I can say is cry me a river.
Here’s what Mozilla has to say about Web NFC, for example:
> We believe Web NFC poses risks to users security and privacy because of the wide range of functionality of the existing NFC devices on which it would be supported, because there is no system for ensuring that private information is not accidentally exposed other than relying on user consent, and because of the difficulty of meaningfully asking the user for permission to share or write data when the browser cannot explain to the user what is being shared or written.
— https://mozilla.github.io/standards-positions/#web-nfc
And here’s what they have to say about Web Bluetooth:
> 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.
— https://mozilla.github.io/standards-positions/#web-bluetooth
The fact is that Google wrote these specifications, couldn’t convince any other rendering engine to implement them, and somehow it’s Apple’s fault the rest of the world rejected their idea.
These are not web standards, they are Blink-only APIs that Google decided to build unilaterally. The web is not defined by whatever Google wants. Web standards are supposed to be arrived at through consensus, and the consensus is that these things should not be part of the web.
>and because of the difficulty of meaningfully asking the user for permission to share or write data when the browser cannot explain to the user what is being shared or written
So fucking moronic privacy virtue signalling BS holding technology back.
They're doing the same thing with Web Bluetooth.
"hurr de durr we can't ask permission" Yes you fucking can, you give me a modal to confirm leaving the current page and being redirected to a new one (in some cases, but not all), you give me a pop up when a site asks to send shitty notifications (as they all do).
An app can sit and use nfc/bluetooth in the background all day long...a site can only do it while I actually have it open in the browser and presumably it's foregrounded etc.
It's really, really NOT hard for them to implement this stuff & I feel like it's less "this tech that has been in phones for more than a decade is unsafe!" and more "we need to cry about features that Chrome is pushing for us to support because otherwise we're letting them lead".
>The fact is that Google wrote these specifications, couldn’t convince any other rendering engine to implement them, and somehow it’s Apple’s fault the rest of the world rejected their idea.
Apple is on the W3C board that gets to decide which APIs become standards. They are preventing these APIs from becoming standards. They have an interest to forbid Web Bluetooth and NFC from becoming standards, because they profit heavily from native apps on their iOS platform, where they collect a percentage of all sales made through apps, so they want to force developers to create native apps instead of web apps.
I'll also point out that Opera, Edge, Samsung and others did implement the Web Bluetooth API, so you are wrong about your assertion that they "couldn't convince any other rendering engine to implement them".
https://caniuse.com/web-bluetooth
If you don't think Apple is abusing their power here, then you are either lacking understanding of how Apple operates, or you just love Apple a little too much.
> Apple is on the W3C board that gets to decide which APIs become standards. They are preventing these APIs from becoming standards.
They are not. You have this almost entirely backwards. To become a standard, you only need two independent interoperable implementations. This means Apple cannot block something from becoming a standard. The only thing Google needs to do is convince anybody else to implement their proposals. So far they have managed to convince precisely zero other rendering engines to do so.
> I'll also point out that Opera, Edge, Samsung and others did implement the Web Bluetooth API, so you are wrong about your assertion that they "couldn't convince any other rendering engine to implement them".
All of these are Chromium / Blink users, not independent implementations.
If Apple won't allow an API onto Safari because it competes with native apps, then why should Firefox bother to implement it? Just because something moves forward in standards, does not mean Apple will ever implement it in their browser. They may never, and so why should Firefox do so, if Apple just blocks Firefox on their platform anyway? Chrome already has the APIs I want on Android, so Firefox won't spend the money to implement a non-standard before it is a standard.
Apple has a lot more control over this situation than Firefox does, and Firefox has limited resources.
Opera, Edge, Samsung and I suspect "others" use the Chromium rendering engine.
Opera, Edge and Samsung run Chromium. They don't use their own "rendering engine".
It's not even features - basic stuff like input handling/focus is broken on iOS PWAs it's an obviously ignored tech.
>It’s hard to delineate which of these are Chrome features or actual web standards. And it’s therefore hard to blame either Safari or Firefox for not supporting them if they’re not standardized yet.
Maybe you don't realize that Apple is on the W3C board that gets to decide which APIs become standards, so they can squash any API that they think could cut into their app store. Citing Firefox as some kind of evidence doesn't take into account the abusive business tactics that Apple uses to force developers to create native apps on their platform.
I don't care about Firefox does, because they aren't forbidding an entire platform from using any browser engine except their own browser engine, which Apple does with Safari on iOS.
So Apple controls iOS browser engines, and they also control which APIs get to become standards. This is plainly abusive. It's also part of the reason Apple is being sued by the DOJ
https://www.justice.gov/archives/opa/media/1344546/dl?inline
You’ve said this above and have been corrected that Apple cannot single handedly veto proposals.
Given the rest of your argument hinges on a misunderstanding of the process I’m not sure it holds much merit.
[dead]
I'm writing this in Safari now, I'm a huge fan. There are several "features" that I actively dislike and disable in other browsers. I wonder if not being implemented in mobile safari is preventing them from being required in some webpages.
* Vibration
* Background Sync
* Bluetooth
* NFC
* Notifications
* Web Push
Notifications struck me as odd. I aggressively disable notifications in my apps because they are often just ads or engagement focused. But as a developer, it would be cool to have a way to notify an iOS user other than building a native app and paying the iOS tax. There's a bunch of utility apps not getting built because of this limitation.
According to this, notifications are possible if you add the app to the home screen, which I didn't know.
A feature more devs should use- I've been surprised how much websites behave like native apps if you just "add to homescreen" instead of downloading an official app, e.g. twitter, instagram.
When you open the shortcut, it doesn't launch as a tab in safari, but appears independently in the app switcher. They are often indistinguishable from official apps!
Seems like a great way for devs to avoid app store pains
This experience is exactly why PWAs could be great.
iOS actually does support notifications in webapps, but only ones that have a homescreen icon. Furthermore, the notification support is different enough that I can't get my iPad to work with Android Messages for Web. So I have no clue if the API is neutered or if Google is being Google and insisting every browser be Chromium. Probably both.
Yeah, I see that list of disabled features as being a feature in and of itself.
Same here. The first thing I do when I install a browser on my desktop is block all that crap in the privacy settings of the browser.
Agree and I’d add WebUSB and WebMIDI. Want to interface with USB? Go through the OS.
WebUSB is incredibly useful to flash firmware and update configuration on random devices.
The alternative is to install random software on your computer for every device (or, if you're a Linux user, you'll likely simply be excluded and whine about it).
Making device companion utilities WebUSB means that when the hardware maker goes belly-up and their site goes down, or just decides to stop supporting a device, it's now a brick. When they are native software programs, someone can preserve them.
Just look at all the old hardware like CNC machines still running just fine on old computers, and imagine if they were connected via WebUSB instead.
WebUSB is just a terrible idea if you're not an ad company.
WebUSB/Bluetooth/NFC/PWAs are an excellent idea.
Not if it's an Open Source project made by a bunch of people for the love of the game. Install a PWA and you have it even when the site is down, if not code available on GH. It's possible to do on a computer (write code and distribute an app not via an app store)...but not in the magical protected-profits land of mobile devices.
Your way of thinking is the reason why we now have a half dozen trillion dollar companies controlling the world.
I’m not sure why web-midi can’t be available behind a permission to control finger printing.
I can think of several light weight patch editors I’d like be able to use. There’s probably not enough demand for someone to make a stand alone app for them.
I can’t see any reason why this needs to be controlled by apple’s app store.
Looking down the list I can find more features that I'd like to yank out of Safari, and Chrome, than features I'd like to see added.
Things that should be removed, according to me:
* Audio recording
* Geolocation
* Motion
* Media capture
You're right, nobody uses video conferencing in a browser. let's kill it!
You have to explicitly allow all of those features to work in a webpage, they aren't on by default, so I'm not sure what you're worrying about.
> so I'm not sure what you're worrying about.
Complexity primarily.
Complexity for who? The user having to click "Yes I want to enable Web Bluetooth for this website"? Or for the developers? Because if it's for the developers, it's literally their job to make complex things simple for users.
I can understand notifications and vibration.
But why not Bluetooth or NFC? I can’t imagine any way those could be annoyances, or even why websites would want them outside of some extremely specialized applications.
I'm personally a WebUSB, WebBT etc hater but I totally get why PWA developers want those features. For example, let's say you're manufacturing some sort of USB device and you need a way to flash drivers. The idea of being able to just make a webpage that can update your drivers is so appealing compared to having to ship apps on Windows, Mac, Linux, iOS and Android.
Similarly, if my bank website could do NFC tap-to-pay securely, that would be pretty cool. I can imagine lots of interesting opt-in uses for NFC in a webapp.
Arguments that these features are held back by Apple specifically in order to keep apps on the app store where they can control things and take 30% at least hold water, I think, even if that reasoning doesn't apply to Mozilla rejecting features.
> The idea of being able to just make a webpage that can update your drivers is so appealing compared to having to ship apps on Windows, Mac, Linux, iOS and Android.
I suspect like many here, at $work we use a shit-ton of Flexoptix SFPs.
Flexoptix are not a $megacorp, they are a (very) small German company.
They manage to ship cross-platform apps to flash the SFPs. So its really not that difficult.
I would think a web app would be more of a pain the the butt to maintain because you have to deal with CSS reactive UI etc.
For little utility apps where you don’t care to deviate from UI default appearance and behavior (and, as a user, it’s much better if you don’t anyway, though it’s very trendy to make UX worse by customizing everything) iOS and Android both are dead simple, very easy to write and maintain a utility app for either of them.
An enormous amount of the cost of developing a lot of native apps is customizing the appearance and behavior, to match some slide deck mockup or to make it “on-brand” or whatever. It’s better for the user, and way cheaper, if you just… don’t do that. Hell a lot of common UI elements are easier in native than web if you just don’t try to customize them a ton (data-backed tables and list views and such are sooooo nice)
I don't know much about Win32, but GTK, QT, Cocoa (Apple),... have nice customization options, and creating custom components is easy.
I like WebUSB in Chrome to update my Meshtastic radios. I also like that I have to go out of my way to launch Chrome for that, and other websites can’t request permission to access local hardware in my normal browser.
Read Firefox' stance of these APIs about users' privacy.
Chromium gives 0 sh*t about users' privacy, and just pump the APIs out for websites to track their users more easily.
Nonsense. Firefox on Android (and I'm sure everywhere else) allows endless redirects without prompting me about the redirect, sending me to sites I never wanted to go to.
And even then, where does one draw the line on "privacy"? Especially given that every other app on the user's phone is granted every permission under the sun and feeding on as much data as possible.
The core of the problem isn't supporting web bluetooth etc or not...the core of the problem is that dumbass humans will go "yes use all the permissions" because their hands are already shaking from tiktok withdrawal.
BT and (although very very limited) NFC can be used for tracking and location detection.
You might want your browser to do Bluetooth, NFC, Background stuff, Face Detection but I don't.
I like to use Apple products for things that are commodities to me because I am not gonna look into the details of those and when I do Apple reasoning often make sense to me (just like this list).
There is a lot more we can criticize about these big tech corps (including Apple) than a product decision for a company that is known for making polarizing decisions on behalf of their customers. If people buy it... they must like it, no?
Then don't use it? These features require explicit permission.
exactly what I do. they are still annoying because providers want to me to be engaged on their terms and keep pushing these features and don’t offer a broad “never use bluetooth on any website ever” kind of option. Magic of KPIs
anyway the point here is that I don’t really care if Safari is behind in support. The article was about blaming Safari for being behind.
Gotta meet your audience where they are. As a Mobile Safari user, the foremost way I feel my use of the web is crippled is that pages assume a bigger screen or are just poorly arranged.
This of all web pages ought to be easy to read on an iPhone screen, but the way it's constructed prevents it. You can't zoom the whole page out to see the entire table width because the table is in a scrolling frame and wider than its box. You can only scroll the nested frame sideways to see how row labels relate to iPhone cells. If you give up and use landscape, it still scrolls vertically in its frame. You have to aim for the margin or else you'll scroll just an inch and be halted because you caught the table.
Because it's critical that the web be as free as it is:
• It's natural that some pages turn out like this
• So it's natural the web is a little bit shitty all over
• So it's natural the demand for richer web features is low
As far as I can see based on pwa.gripe data, between 26.3 (my version) and the newcoming 26.4 Safari on iOS gains support for five new APIs:
— Offline support
— Media capture
— Picture-in-picture
— Storage
— Speech synthesis
As well as five more APIs with caveats:
— Installation
— Notifications
— Web Push
— Barcode detection
— Speech recognition
Even taking into account that it also evidently loses support for one (audio session; I wonder if that that has to do with potential for fingerprinting), framing this feature differential between two minor(!) releases as “intentional crippling of Mobile Safari continues” strikes me as somewhat loaded.
Do you have a source link for this? I don't want to sound snarky, but this list doesn't make sense to me.
Offline support has been available (and buggy, YMMV) for a long time.
Web Push has been available since 16.4 (with a lot of caveats)
I haven't heard anything about installation (but I may have missed something)
My source is TFA, as I stated. This is what I see in the table when I follow the link.
For example, in the column for my current iOS version offline support is crossed out, and for the upcoming version it has a check mark.
If the claim being made is that pwa.gripe is a bad source, I can only assure I have nothing to do with the site. If they misinform visitors about Safari’s capabilities with regard to PWAs, you should post it as a top-level comment.
The source is caniuse.com data. The build script for the page is open-source as well.
https://github.com/leoherzog/pwa.gripe
Worth noting that Apple doesn't just cripple iOS Safari, it cripples all iOS browsers because it also forces them to use WebKit, the crippled browser engine underneath Safari.
It would be fine if they just made Safari bad, that's their choice. But they don't stop there: they make the entire web bad on iOS purposely to promote the native apps they can tax.
Firefox was planning a native gecko based ios app. But Apple decided to limit it to EU forcing developers to choose to maintain seperate projects for a limited users.
The Brussels Effect takes care of a lot of hardware changes for the better, for the world (think USB-C).
But for software, not so much.
Examples:
* Windows N (no media player stuff) and KN (no media player stuff, no messenger)
* Windows installed in the EEA (ability to disable / change start menu search with Bing, ability to remove Edge, ability to add widget providers)
* iOS with only allowing 3rd party app stores and 3rd party browser engines in the EEA.
* Google only allowing certain things when the phone is in the USA.
And it's gonna get worse with age verification. All of the sudden the manufacturers have even more data.
This is clearly for reasons of security.
I don't think Apple is terribly interested in market share for Safari. What they are interested is preserving their competitive advantage in privacy.
The security/privacy argument has been debunked many times.
How do you explain that all other OSes, including Apple's own macOS, manage to allow other browser engines?
Do you think the iOS team is that incompetent?
iOS is much more secure than macOS.
Debunked where? Do you even understand what a web engine does?
If it's about security and privacy, why push more people away from the Web to native apps that they know is less secure [1][2]?
> WebKit’s sandbox profile on iOS is orders of magnitude more stringent than the sandbox for native iOS apps.
[1] https://assets.publishing.service.gov.uk/media/62277271d3bf7... [2] https://open-web-advocacy.org/apple-dma-review
Native iOS apps are sandboxed and even more secure. The reason the web engine is tied down is because web engines are insecure by nature. And now you want Apple to allow anyone to write one?
> I don't think Apple is terribly interested in market share for Safari
Google pays Apple $20B a year because of the market share Safari has on iOS.
I'd call that "interest"
That's 10% of their turnover (and likely mostly pure profit, as they seem to spend a fraction of that on Safari)
Try again. Anyone can write a browser that uses the existing web engine and connect it to any search engine they want. Make it popular enough, and they can made a deal with Google.
Having Safari is a default browser is another (valid) issue, but that is a separate concern from the web engine.
[dead]
Like most people (at least on this thread). I’m okay with the vast majority of these things not supported in mobile safari. But man, Bluetooth would be nice. I often provision esp32 devices for various things and either I need an app or a laptop when my phone is perfectly capable.
Yeah it's killing me too. I make a product that's MFI certified and I still can't use a browser to talk to it.
I built https://pwascore.com/ several months ago.
Where pwa.gripe cherry-picks and has an axe to grind, pwascore.com is intended to be a more thorough and dispassionate evaluation. I will add desktop browsers soon.
Click "Expand All" for a complete and detailed list. Click "How Scores Work" to understand the scoring heuristics.
Well the notifications on your web site doesn't provide the full idea of how limited it is in Safari. We have to ask users to install the shortcut before allowing notifications with Safari. Guess how many users actually go through with installing the shortcut? Nearly none.
If we had to ask users to go into their settings and switch the "enable notifications" flag we wouldn't call that supporting anything. The whole process of installing a shortcut to even get to the point where we can ask for notifications is even more convoluted on iOS.
[dead]
How did you determine the weighting for your scores?
The most significant effect is that experimental and non-standard PWA capabilities aren't reflected in the primary score. You can see raw/unweighted scores by hovering over the primary score. Chrome wins handily if you count experimental/non-standard features.
For standards-based features I used a 4-tier model, described about halfway through the README (which I should also add to About):
This weighting turns out to be reasonably conservative. For example, if you hover over the score for Firefox (the largest benefactor), you'll see that it bumps Firefox's score by 5.I'm very open to feedback. This is a sincere attempt to quantify vendors' PWA support.
It's a cool page, although somewhat limited in scope. If you want a more complete picture of all the web progress Apple is holding back, not "just" PWA and more advanced capabilities, this is probably a better site for comparison:
https://ios404.com
It includes dates for when these things were first shipped, explanations for that they do, and what kind of standards (or not) they are.
Note how it doesn't list which of these are Chrome-only non-standard APIs that Firefox doesn't support either.
Oh wait. You don't care about small details like that. None of these Chrome shilling websites do.
Did you try opening the page? Each feature says which spec it's part of (e.g. "W3C Draft", "W3C Candidate") with a link to it. It also shows which browser implemented a feature first. Often it's Chrome, but sometimes it's Firefox, Opera, or even desktop Safari!
Likewise, you can click on the Chrome icon to change comparison browser. Here's a list of features implemented in Firefox on Android but not in Safari on iOS (and therefore, not in Firefox on iOS either):
https://ios404.com/?browsers=andff
Fwiw, I've been a Firefox user for about 9 years. I would love to see Firefox be able to ship their engine on iOS. The main reason Firefox haven't implemented as many features as Chrome is that they lack the resources to. Anti-competitive behaviour has hurt them a lot, and being forced to use a sub-par, undifferentiated browser engine on iOS - the world's most valuable and influential OS, has played a big part in this.
First of all, features can be a standard without (full) FF and/or Safari support.
Second, Safari has a monopoly on iOS and controls what other browsers can support on the platform (that also usually means "less than Safari", because SF gets to support things first). They are in a unique position to hold back the entire web, even on other platforms. They're holding the standards hostage by not allowing the market to decide which features are important to them (and put pressure on Safari and FF to implement them)
> First of all, features can be a standard without (full) FF and/or Safari support.
No. No they can't. A feature that is shipped in a single browser is just that: that browser's non-interoperable feature.
We literally lived through this with Internet Explorer.
The only reason the web is thriving now is because browser vendors agreed not to push this shit any longer. Well, until Google decided that whatever it does is the web, and until people who are not even paid by Google started unironically pushing the idea of "whatever Google spits out is the essential web standard now".
I mean, the status of multiple APIs on any of those "Safari is bad PWA is good" sites are literally in the "it's a napkin scribble, not on any standards track".
> They're holding the standards hostage by not allowing the market to decide which features are important to them (and put pressure on Safari and FF to implement them)
Who puts the pressure on FF to not implement Chrome-only non-standard APIs? Even desktop Firefox doesn't want to touch that pile of garbage with a 10-yard stick. And yeah, let's not pretend that Chrome somehow got to where it is by "market deciding".
> A feature that is shipped in a single browser is just that: that browser's non-interoperable feature.
AFAIK, the popover and/or anchor positioning APIs was standards before it shipped in more than one browser. (I will say that all three(?) of them agreed to build it)
> "it's a napkin scribble, not on any standards track".
Chromium/Blink have a process, and it's quite rigorous (precisely because they understand that they're pushing things, so they have a responsibility to make sure it's good):
https://www.chromium.org/blink/launching-features/
> I will say that all three(?) of them agreed to build it
This is the key sentence
> Chromium/Blink have a process, and it's quite rigorous
It's Chrome's process, and Chrome's deadlines.
> they have a responsibility to make sure it's good)
Strange then that they routinely don't wait for and ignore any and all input from other browser vendors and ship their own APIs without any consensus or agreement because "their rigorous process is good" or something.
E.g. almost every single API marked as "experimental" on MDN docs [1] is already shipped in Chrome despite most specs being "not on any standards track", "has multiple issues", "no consensus and API is in flux" or "it is provided for discussion only and may change at any moment."
[1] https://developer.mozilla.org/en-US/docs/Web/API
Hi! Creator here (of iOS404) - you can filter level of standard and compare to FF Android (or compare to Safari Desktop, or any mix) instead if you'd like.
Amazing site. Thanks for making it.
Of course! Thanks!
It's called iOS404, not "FF" or "Chrome" and pushes the narrative that iOS is bad, and missing features.
There are 34 features listed (IIRC it did contain a bunch of Chrome-only crap once upon the time, hence my harsh reaction). All of them enabled by default. If we limit this only to actual, you know, standards, and not "scribbled on a napkin, awaits review", we get a grand total of 9 (yes, nine). And even there many are not "not implemented" but "missing some features (sometimes big, sometimes small and irrelevant)".
Are you mad because they probably found the same thing I did when doing web stuff that had to run on iOS (going as far back as about 2012~) that iOS required so much more hoop jumping, hacks, polyfills etc? It was just assumed that every other platform worked fine, time was always allocated for inevitable issues on mobile Safari.
Yep - the site has a point of view but rooted in real data that you can filter as you'd like.
I've had real-world experiences where I develop something that works on my Mac and my Pixel phone but cannot work on iOS WebKit (basically kaputt on iPhones). It inspired the creation of the site - specifically not being able to allow users to have Audio at anything but 100% seemed extremely weird.
I'm not offended by sites that also point out issues with a slant against Google. Ie: killedbygoogle - I think these things are great, fun, and interesting.
Google has become the developer-focused company that Microsoft used to be, and I don’t mean that positively. Developers are lazy and want to inflict low-effort crap on users. Microsoft always made it easier to do that. Google is now doing the same thing. Offering developers more and more ways to cobble together box-checking functionality in web apps instead of developing proper native apps.
> Google has become the developer-focused company
They’re the advertiser-focused company. Bluetooth and NFC aren’t being exposed for developers first.
The advocates of ChromeOS Platform keep pushing their agenda.
Chrome APIs and Electron crap, and then everyone complains about Microsoft.
Author here. I have no affiliation with Chrome, and use Zen and Firefox Mobile pretty much exclusively. I recently made an ESP32 hardware side project that I can configure entirely in the web browser via Web Bluetooth, got hyped, then immediately sad that my page was never going to work on iOS / iPad OS. So I threw together this webpage from caniuse.com data.
No average person cares about your side project, and most people prefer Apple’s product decisions over the ones you’d like them to make. Based on your history with technology, you are a Windows developer who would like to distribute apps on Apple’s platform without learning about what makes for a great app on that platform.
Firefox doesn't do Web Bluetooth.
https://bugzilla.mozilla.org/show_bug.cgi?id=674737
To be fair, some of these features are security issues some users don’t want to have in their browser.
Yes I want more shitty web apps. Also you can’t imagine how much I love cross platform Electron apps.
I have no desire for random websites to have that much access to my phone.
People like you could turn off these features and continue installing and updating native binaries for the Starbucks app or random hardware companion apps all you want. I'd like first-class PWAs please.
Funny enough, I just replied to someone who posted a link to the great lengths Slack is going through to make it use less memory on the desktop.
https://slack.engineering/reducing-slacks-memory-footprint/
When the obvious answer I gave about how to reduce the memory footprint and make it more performant was “to stop using fucking [web technologies]” and create a native app
But the question I always ask people who say that it’s mean old Apple keeping PWAs back, why is it that all of these same companies see a need to create an app for Android?
To your last point surely it makes sense that they'd probably be rolling something like RN or similar where at that point they may as well build for Android app as well right?
Versus with proper PWA support across the board, a single button on the company's site that installs a PWA no matter which platform your customers are on.
Papa John’s doesn’t need a website seemingly and everything you can do on the app you can do on the website. Why is the app so much faster? I can say the same for banking apps, Airbnb, hotel apps, etc
There must be some reason that every major company decided to have an app even though today all of the same functionality is available on the web.
Average people don’t want to spend their lives managing permissions. You could go ahead and use Android or ChromeOS.
[dead]
I argue that developers enable the egregious behaviour by supporting safari in the first place. Just as IE was called out and shunned for its shenanigans, before they started behaving better, so too does safari need to be treated. However, it does also feel too late, they have crippled other browsers too with their platform abuse masquerading as requirements while we celebrated it.
Is it really egregious that Apple doesn’t support everything Google decides to push? Most of these are features I don’t care about, or in some cases actively do not want.
I’m also not sure how accurate this page is. They claim Chrome on Android supports registerProtocolHandler while MDN says it’s not supported there.
Ah yes, let’s break our site for 1.56 billion people to stick it to apple.
Also WebUSB, WebMIDI. Not to mention that you can’t develop an app for you (and your family and friends) without have developer subscription :(
Yeah, I don't want background sync. I mean, iOS is built upon the idea that any task in the background might be killed at any time and without warning by the OS. This is so the OS is able to manage battery and memory effective.
You can of course dislike this, but not even native apps allow background sync anyway, so of course web apps would not be allowed to do this either.
I feel like the vast majority of these are features of an operating system? Not a web browser?
The web is a developer platform, not just a static document viewer.
Ragebait page.
I left after seeing Contact Picker API listed. Contact Picker API is, per the MDN link in the OP, marked as "This is an experimental technology." It is "not Baseline because it does not work in some of the most widely-used browsers."
None of this is an issue, the real issue is webpages not working in safari due to large part of the web being made exclusively for chromium.
This is the current choice developers face - build for the app-store or build for the web. Or both.
For me, I honestly don't care if Mobile Safari seems 'crippled' when everything I use works exactly the same on devices as on Firefox/Desktop. If anything I'd be more annoyed if it worked better on my fringe devices, but maybe I'm the outlier here - I only use mobile for comms/banking, tablet for light browsing, and it's more often I'll be on Desktop.
Do I think it should have less functionality in Mobile Safari - yes if I get more battery life. Conversely no, if those features could give me more battery life back through intelligent apps.
For those of you who believe support for PWAs is critically important: in what way does it impact you? What kind of solution are you providing (or, put another way, what problem are you solving) for customers, and why would a PWA app be better than a native one for them? (As opposed to, say, convenience for you.)
Businesses tend to relay costs onto their customers (someone has to pay the bills).
- The app store tax
- The extra work of maintaining at least 2 separate apps (iOS, Android, optionally(?) desktop web app)
- Dealing with app store rules
Some of these are not just costs. I have experience with native apps that have to make things worse for users (compared to the web app) or risk getting booted off the app store.
What outcomes are worse for users that arise out of you offering native apps?
I thought this was obvious, but higher costs for building and maintaining an app (vs a web app) means higher prices for users. I think people would love to pay less, and would hate to pay more.
How much is the incremental cost per user?
Building the same app for iOS, Android and desktop: up to 2-5 times the costs (for businesses, how they cover those costs depends)
App tax: 15-30%, which can drive the price for consumers up by up to 44%
https://open-web-advocacy.org/walled-gardens-report/#negativ...
What I’m looking for is an answer from you as it relates to your specific business, not speculation from an advocacy org that can gin up any hypothetical numbers they want.
I asked in the start of the thread: how does it impact you, or your customers?
Native app development needs work on all major platforms. But in the long term I don't think web apps are the way out.
I keep asking: Android doesn't have all these perceived limitations. Where are all the amazing native-like PWAs on Android?
If a web app doesn't work on iOS, a business builds a native app instead. iOS is too important. So that fantastic native-like PWA never gets built in the first place.
Apple is not just holding back PWA on iOS, they're holding back the entire web everywhere.
Compare that with desktop, where web apps (maybe not PWAs, strictly speaking) are dominating: Gmail, Office/Docs, GitHub, Figma, you basically do everything in web apps.
And if you count Electron [1]: VSCode, Slack, Spotify, etc, etc.
[1] Importantly, Electron lets you bring your own (browser) engine. You can build a native app on iOS that is just a wrapper around a web app, but it has to run on iOS' WebKit, and is thus limited by what Apple deems worthy
There are many countries in the world where iPhones have hardly a presence, yet they also don't have PWAs.
https://gs.statcounter.com/os-market-share/mobile/africa
First of all: don't they? (honest question, I truly don't know if Africa has more PWAs compared to US/EU/etc)
Second: There are many reasons why businesses would opt for a native app. Notifications, for one (not available on the web on iOS until just a couple of years ago). Also, native apps allow for more tracking (whereas browsers are paranoid by default).
Third: A few years back, companies like FB, Google and Twitter all launched "Lite" versions of their apps, specifically targeted at Africa and other developing markets. They were all web apps (or wrappers around web apps). I will admit that this was years ago, and I have not checked if these Lite versions are still around and/or widely used.
> If a web app doesn't work on iOS, a business builds a native app instead. iOS is too important. So that fantastic native-like PWA never gets built in the first place.
So, instead of hiring a team to build an amazing PWA for Android, and an app for iOS, business hires three teams? One building a web app, a native app for iOS, and a native app for Android?
> Compare that with desktop, where web apps (maybe not PWAs, strictly speaking)
Indeed, these are not PWAs, not even strictly speaking. Also, they all depend on full desktop browser to work (often due to sheer fact that they are complex apps that don't work well on mobile screens), and none of them including Google have an amazing native-like PWA experience on Android.
I mean, you're bemoaning iOS crippling PWAs on iOS. It should be so easy to show amazing non-crippled PWAs on Android. After all, we've been told for the better part of the decade that PWAs are amazing native-like now. Android's market share is 68-70% worldwide. You'd think someone would finally be able to show the full power of a PWA? Anyone?
> And if you count Electron [1]: VSCode, Slack, Spotify, etc, etc.
One of them has millions of man-hours and millions of dollars of investment to make it somewhat performant. The others struggle to show a few pages of text and images in less than 1GB or RAM. Not the flex you think it is.
> business hires three teams?
Yes. The web's winning feature is "it works everywhere". If your app doesn't work for the wealthiest 50% of users, why go that route? Making a desktop web app work on mobile, just for Android, is a lot of work. It needs to work on both iOS and Android to make it worthwhile.
> they all depend on full desktop browser to work (often due to sheer fact that they are complex apps that don't work well on mobile screens)
Gmail, Office, Docs - they all exist on mobile (as native apps). So it's not the complexity itself that makes it a problem on mobile screens. What does the native Gmail app do that the desktop web app doesn't?
> Android's market share is 68-70% worldwide.
Not in the wealthiest parts of the world, where the money is.
> Yes.
> If your app doesn't work for the wealthiest 50% of users, why go that route?
Why doesn't business hire two teams? One for the amazing native-like PWA, and one for iOS?
> Making a desktop web app work on mobile, just for Android, is a lot of work.
More work than hiring a separate Android team? More work than hiring a team to create a PWA which we've heard continuously for the past 10 years is amazingly easy and native-like?
> Gmail, Office, Docs - they all exist on mobile (as native apps). S
Yes, yes they do. As native apps
> Not in the wealthiest parts of the world, where the money is.
In 10 years you'd think we'd see actual examples of these amazing fast native-like PWAs on Android. All we hear is excuses.
Funnily enough I know of a few. E.g. Foodora's web app is surprisingly good, and it's possible that their "native" app is just running inside a webview, since it's indistibguishable from their website. But even MORE funnily enough, it takes a PWA sceptic to spot good PWA apps when none of the PWA proponents can point to a good PWA to save their life.
Websites don't need any of that. If you want to make software for an iPhone you can make an app.
“Catholics think Protestants are kooky” is a news headline that would work anytime in the last 509 years.
How many of these features that chrome offers have been fully flushed out and in a true working stable state? Google Chrome has a habit of pushing features out before they're really ready and Safari is usually on par with Firefox for features from what I have seen.
It's not a question of readiness or capability. It's an MBA with a spreadsheet explaining to a room full of people how much money Apple will lose if they allow X feature to work in Safari. This is user-negative behavior from a company that has so much money the best thing they can think of to do with it is to bank it offshore in a tax haven.
Conversly, there is an MBA at google saying how much money they can make for each extra piece of data they can extract off the user’s phone.
I agree an open web platform is good. But i also think some of the things added to the browser don’t belong in the browser. Face detection? i don’t need that.
I am much more partial to attempts to force apple to enable installing 3rd party apps than i am forcing them to bloat the browser with more ways for websites to monitize me.
> It's an MBA with a spreadsheet explaining to a room full of people how much money Apple will lose if they allow X feature to work in Safari.
You forgot to mention the long mustache your cartoon villain MBA is twisting while they sabotage Safari.
Crippling web apps is a user-positive behavior. It just so happens that user’s incentives and apple’s incentives are aligned.
I’ll ask the dual question: how many of the mobile safari checkmarks are fully fleshed out? Media Session has a check, but I have absolutely fought obvious Media Session implementation bugs in my own PWAs when designing for mobile safari
This isn't about browsers, it's about Apple spending the last decade blocking PWAs on their platform by intentionally breaking something new with every new OS release, thus forcing people to build and ship bloated pointless 50meg webview packages through their aPp StOrE every time they update the width of their sidebar.
PWAs are great. They were literally Steve Jobs' original vision for the iPhone. I don't know why people are arguing about Firefox or the individual features - that's not the point, they're not the ones that matter. It's the decade of sabotage.
> PWAs are great. They were literally Steve Jobs' original vision for the iPhone.
Was it? I think one of IOSs strength is its operating system and proper native apps. PWAs are inaccessible, bloated, slow and awkward to use.
> Was it?
Yes. Here's a quote for you from the original WWDC 2007 iPhone launch[0]: _"We've come up with a very sweet solution. An innovative new way to create applications... it’s all based on the fact that we have the full Safari engine in the iPhone. And so you can write amazing Web 2.0 and Ajax apps that look exactly and behave exactly like apps on the iPhone! And guess what? There’s no SDK that you need!"_
> I think one of IOSs strength is its operating system
one of the OS' strengths is its OS, cool
> and proper native apps
not what we're talking about here at all
> PWAs are inaccessible, bloated, slow and awkward to use.
literally the opposite of all those things
[0]: https://www.youtube.com/watch?v=p1nwLilQy64
> one of the OS' strengths is its OS, cool
Woops, messed up the wording there.
It's an interesting way to go about it. But I am not sure it's the same as what we get now. We aren't just leveraging the webkit renderer, we are using the browser as a complete OS/runtime for your applications. On top of an OS that already has its own UI libraries.
The current standard is that when you visit a webpage you are downloading an application in the tens of megabytes. In 2007 that would barely be possible.
When I think of PWAs I think of Microsoft Teams. It's slow as a website and somehow slower as a >100mb "native" app.
Anyway thanks for the reference. I am curious how much the current method strays from what Apple envisioned back then.
Native apps were never a part of the original iPhone release, all the apps were essentially web apps, running one at a time (no multi-tasking/running in background unlike it being built into Android from the get-go).
I'm not sure the other commenters claiming all these features are attack vectors actually read the list?
How is the barcode detection API a security risk for example? Having it implemented would be amazing for web apps.
Also there's features like deep linking into PWAs that ought to be pretty basic PWA functionality that's not on this list that even Safari on Mac OSX has but Safari on iOS doesn't. Even the add to home screen menu option is deliberately made hard to find.
Apple doing this for the benefit of the user is one of the less likely hypotheses.
Google never really cared about Chrome on iOS. They barely care about Chrome on Android to be honest, that app still looks and feels more or less the same it did 10 years ago.
Yes, they can't bring their own engine, but it's in their interest to lock users in and ensure they continue using Chrome on iOS. But it took them years to implement available APIs like passwords (AFAIR it was out for 3-4 years before they allowed Chrome iOS to supply your passwords).
This table could stand to have a desktop safari column. For instance folliwing the "shortcuts" link https://developer.mozilla.org/en-US/docs/Web/Progressive_web... says "safari: yes (17.4), mobile safari: no". So it's not like Apple is fully against at least some of these APIs.
it doesn't eat into AppStore sales to support it on mac because most use non appstore apps anyways. on iOS, PWAs are the one alternative to apps that Apple can take a sales cut from, which makes them a threat to their services revenue
As a daily Safari on iOS user, I don’t care about any of this, but since iOS 26 basic Safari features such as bookmarks and text search have become so buried deep underneath, they are basically unusable at this point.
It infuriates me a lot more than all the liquid glass stuff (on which I’m neutral overall).
I had to double check i’m running ios 26 because none of those things have moved for me recently.
Search is where it always was (type in the search bar, scroll past the google results to the in-page results) and bookmarking is also where it’s always been (share button “add bookmark”)
Damn. I never knew that way to search things. I used to do « Share / Search on this page » which was already obnoxious, which has now become « … » / « Share » / « Search on this page ».
Either I’m dumb or there is a discoverability problem with all these features. Probably a bit of both.
If you go to settings > apps > safari, and scroll to the “tabs” secttion, then turn off “compact” you get rid of the “…” button and go back to what it used to look like before.
Which is why i didn’t notice the change, as i had already set this setting to put the url back at the top an update or two ago.
And yes, definitely discoverability issues.
Yes. "Add to homescreen" is in the "Share" menu.
That's where they burry all bodies.
A friend was telling me yesterday that this is how you can set custom ringtones on iOS. He seemed really excited about it, how cute.
Because I literally could not believe the archaic process previously used until very recently to set a ringtone on iOS. And now it's under the share menu?! Why do Apple people put up with this shit?
I've been able to set a custom ringtone in Android from the OS settings/any file browser app for at least 15 years and I would not be surprised if Android launched with it.
>Apple still sells 30-second song ringtones for $1.29 each through the iTunes Store app.
Oh...alright well now we know why.
Isn't that where it's been for ages?
It’s been there since literally iPhoneOS 1.0. They are calling it “share” now, but really it’s always meant “put / send this somewhere”. The difference with recent versions of iOS is that the share button is no longer always visible but you need to press the ellipses button to reveal it. It’s there along with all the other dastardly actions Apple doesn’t want you to know about, such as “Add to Favourites”.
To be honest, I'm really surprised they let PWAs have notifications. That's literally the only use case we have on that entire page and it actually works.
The irony of this webpage being terribly optimized for mobile clients…
Nested scrollbars! Horizontal and vertical scroll!
I want location permissions for web apps installed to the home screen to be separate from Safari.
I want to auto-deny websites asking me for location permissions. But I want to be able to grant location permissions to installed web apps on a case-by-case basis just like with regular apps.
Agreed. Very reasonable, very simple, and already possible on Android.
Apple's intentional protection of me from unsavory developers boundary pushing of the listed items by Mobile Safari
Used to have Firefox as a content filter for Safari on iOS (adblocking), but have since switched to Brave. It's a great option if you ignore all the crypto spam.
> if you ignore all the crypto spam
you can disable all those "features"
Well at least you can set a custom search engine URL – oh no, you can't, that would probably endanger some children or something !!
hey the AR/VR entry is wrong, right? Apple demonstrates it in the keynote webpages by having a 3D model relating to the keynotes' themes that can be placed and rotated in space, I doubt it would be for their own pages only.
unless it means having the webpage itself render in VR and not just an isolated model
Imagine if these countless of "Safari bad" sites didn't shill for Chrome by pretending that Chrome-only APIs are essential and standard web apis.
> Chrome by pretending that Chrome-only APIs are essential and standard web apis
Reminds me of the days when all the corporate coders thought the IE apis were the only ones worth using.
So if you accessed $megacorp website on a non-IE browser it was your fault for not using IE and not their fault for failing interop.
I noticed how they've marked the features that only Chrome supports (e.g. installation) but not the feature that only Firefox supports (orientation).
(tbh I don't know if the list is simply Chrome-centric or if there's a good reason behind, but it struck me as interesting)
yeah I'm using mobile Firefox and it has an awfully high overlap with Safari. Almost like a bunch of the stuff Chrome supports isn't actually a standard at all yet...
For me, the biggest hurdle to writing a PWA is the insane installation process [1]. There are also a ton of quirks, eg I don’t think you can update the icon if it’s installed as a PWA. It is hard to argue that this whole process has not been hobbled intentionally.
1. https://www.reddit.com/r/webdev/s/yVERKqoJgb
I recently posted about how I refuse to buy apple products because of stuff like this. The lock in has made iPhone users dependent on a app ecosystem when we could have had most of our functionality through the open web.
People saying they don't want these features are missing the point. Its about control and if developers have the option to make something as a website that actually works that gives them less incentive to make an app that apple can take 30% of your profit from while you are forced to write in their proprietary language for the stuff that only works on their devices.
So much engineering duplication of effort and waste just to satisfy a bottom line.
Break the app store monopoly, don’t make the web browser into a buggy leaky bloated mess.
And you can write iOS apps in objective c, swift, kotlin, jacascript, rust, ruby, and a few dozen other languages.
The web can be a competitor for the app stores, breaking that monopoly. It already did on desktop (where most users spend > 90% of their time in a browser)
And yes, you can write native apps in a lot of languages, but you can't choose how/where you distribute.
On the web, you can. It's built that way.
Except one of the main things i like about the web is that websites don’t have invasive access to my life. The web-as-app-platform idea erodes that.
But either way the issue is the same - apple preventing us from installing what we want. But my solution protects freedom in a more robust way: if you break the app store monopoly, you can install chrome or firefox and do all the web-app-platform nonsense you want. If safari adds all the features on that list you’re still stuck demanding apple add a new feature every time you want to innovate.
And as for programming - for the web you can write in a lot of languages but you only have two options For debugging - js and webassembly.
> if you break the app store monopoly, you can install chrome or firefox and do all the web-app-platform nonsense you want
Apple would also need to be forced to provide the APIs that browsers need so they can properly integrate with the OS (a lot of those APIs are private, currently), but good point, that would absolutely be one way to break this open.
“Private api” is fairly meaningless outside of an app store context. The symbols are easily extracted and headers can be re-constructed in minutes. The issue has always been that if you use these apis your app will be rejected from the store.
I very much appreciate the secure baseline Safari settles on. The entire ecosystem is protected by Safari being slow and reasonable.
My only peeve is that Apple resets the feature flags with every update. So the one experimental feature I use I have to reenable each and every time I get a phone update.
I just want less ads.
It'd be nice if desktop safari was a column.
the author puts a lot of unchecked boxes to the top, trying to make their point.
Frankly I am very happy indeed for Apple to "cripple" Safari.
99.9% of the things listed in that stupid table in the blog just stink of being potential attack vectors.
And we know just how heavily smartphones are targeted and how smart and sneaky some of the latest vectors are.
Related: Firefox stance on Google's web proposals: https://mozilla.github.io/standards-positions/
This is just Google/Chrome apologia. Big nope from me, dog.
there’s a .gripe TLD now? this is the form feeling old comes in for me
I would gladly give up all those “features” to use Safari over Chrome on Android. I don’t even know what kind of dumbass on Hacker News voluntarily raw dogs the internet on Chrome Android. Pathetic that Safari has had extension support for multiple years now while Chrome is still ass.
Absolutely nothing listed on that site as unsupported by Safari has any business being part of the web. In fact several supported APIs should be chucked too. Fuck giving websites motion data or push notifications.
They should just ban unsolicited prompts. That's it.
Push notifications are the #1 featured requests of my online community. Some even switched to Android over it.
And people don't understand adding sites to their homescreen, especially since Apple buried that feature in the Share menu.
No Android user of my website ever complained about the WebPush notifications.
I don’t care what your website does, not one tiny bit. I care that the majority of websites are shit, and therefore the web platform should be as minimal and isoltated from the device as possible.
Well my website isn't shit so I don't care about your opinion.
> Push notifications are the #1 featured requests of my online community. Some even switched to Android over it.
That sounds like the market working, no? Some people like how Apple does things, so they stick with Apple. Others prefer Android, so they switch.
The point is that users should have choice, not force users to bend to the will of malicious developers.
Does android still give you a push notification to dismiss whenever you take a screenshot?
No.
Some people feel just as passionate about OS-level notifications and location permissions, and they turn them off. You can turn them off in your browser's settings as well. You'll be okay.
Yeah sorry but as an end user I’d rather have an actual app than some PWA thanks.
Keep going Apple.
This is the first time I've actually heard the opinion that someone thinks we need more apps instead of more functional websites.
These are not features of functional websites, these are features that make every website an "app" and deprecate the idea of a traditional website. Google is embrace, extend, extinguishing the web as we know it. If Apple gives in, it's over, every website will just be an app and want access to your contacts, and your family history, and whether or not you are on Santa's naughty list or whatever.
I think it reflects the general HN sentiment that native apps > progressive web apps.
Functional websites would be wonderful.
Instead we get “webapps”.
Better PWA support gives users (and developers) more optionality with app distribution. Apple building out these APIs would not take away from their native apps.
The UX of visiting a site and with a single click of a button having an app on my home screen sounds great. I'd also like to have the option of side loading a native app too. And if those options sound unappealing, you can keep using the App Store if you want the assurance of using an 'officially approved' app.
A lot of very prominent apps are written using web technologies anyways. Take a look at the continued popularity of React Native (and Flutter as well).
> A lot of very prominent apps are written using web technologies anyways. Take a look at the continued popularity of React Native (and Flutter as well).
And it shows through their laggy interfaces and non-native UI/UX. The people don't like apps built with web tech; developers and LLMs like them because they're a shortcut.
> The people don't like apps built with web tech
Then why do most people spend > 90% of their time in a browser (or web-powered app) on desktop?
Irrelevant, we're talking about mobile here.
How is that irrelevant? Isn't it important to ask the question "why did this thing work on desktop, but not on mobile?"
No choice.
Funny you would say that. Because businesses and users have only one choice on iOS: native apps, because the web app isn't viable (and/or available) on iOS.
Yeah, it’s great.
Thank God. Thank God! Too much going on these days.