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
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
> 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.
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.
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)
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.
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?
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.
>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
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'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.
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.
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.
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?
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."
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:
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.
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
On my phone I use a browser that's based on the same engine as Safari (Epiphany) and zooming the whole page out to make it use a wider layout and then zooming it in without relayouting with a pinch gesture is trivial.
A good tool empowers the user when presented with imperfect reality.
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.
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.
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.
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.)
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.
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
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.
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.
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”.
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.
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.
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.
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.
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.
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.
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.
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...
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.
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
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.
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
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.
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.
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)
Sonehow you seem to confuse open web with Chrome-only non-standard APIs
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)
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?
Firefox refusing to implement a web standard: APPROPRIATE
Safari refusing to implement a web standard: INAPPROPRIATE
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.
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.
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).
> 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.
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
I have no desire for random websites to have that much access to my phone.
1. https://www.reddit.com/r/webdev/s/yVERKqoJgb
* Vibration
* Background Sync
* Bluetooth
* NFC
* Notifications
* Web Push
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
Things that should be removed, according to me:
* Audio recording
* Geolocation
* Motion
* Media capture
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.
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.
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.
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 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.
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?
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."
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.
Oh wait. You don't care about small details like that. None of these Chrome shilling websites do.
— 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.
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)
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
A good tool empowers the user when presented with imperfect reality.
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.
I don't think Apple is terribly interested in market share for Safari. What they are interested is preserving their competitive advantage in privacy.
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.
Chrome APIs and Electron crap, and then everyone complains about Microsoft.
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.
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.
You forgot to mention the long mustache your cartoon villain MBA is twisting while they sabotage Safari.
It infuriates me a lot more than all the liquid glass stuff (on which I’m neutral overall).
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”)
Either I’m dumb or there is a discoverability problem with all these features. Probably a bit of both.
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.
That's where they burry all bodies.
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.
you can disable all those "features"
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.
And you can write iOS apps in objective c, swift, kotlin, jacascript, rust, ruby, and a few dozen other languages.
Keep going Apple.
Instead we get “webapps”.
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).
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.
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.
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.
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.
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.
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.
(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)