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
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?
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.
Your statement is true only outside of EU countries.
It doesn’t necessarily change the point in the end but it is worth noting.
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.
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.
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
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.
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.
Here is HN, where apple is the bad boy in town.
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.
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).
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.
> 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.
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".
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.
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
Given the rest of your argument hinges on a misunderstanding of the process I’m not sure it holds much merit.
* 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
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).
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.
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.
Chromium gives 0 sh*t about users' privacy, and just pump the APIs out for websites to track their users more easily.
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?
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.
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
— 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)
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.
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.
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.
I don't think Apple is terribly interested in market share for Safari. What they are interested is preserving their competitive advantage in privacy.
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?
> 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
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)
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.
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.
For standards-based features I used a 4-tier model, described about halfway through the README (which I should also add to About):
┌────────┬──────────────┬───────────────────────────────────────────────┐
│ Weight │ Tier │ Rationale │
├────────┼──────────────┼───────────────────────────────────────────────┤
│ 3.0 │ Core PWA │ Prerequisites for production PWAs (6 features │
│ │ │ features: Web App Manifest, Service Workers, │
│ │ │ Caching, HTTPS, etc.) │
├────────┼──────────────┼───────────────────────────────────────────────┤
│ 2.0 │ Important │ Enhance PWA functionality (18 features: Push │
│ │ │ API, Add to Home Screen, Offline Support, │
│ │ │ Display Modes, etc.) │
├────────┼──────────────┼───────────────────────────────────────────────┤
│ 1.0 │ Standard │ Default weight (94 features) │
├────────┼──────────────┼───────────────────────────────────────────────┤
│ 0.5 │ Experimental │ Nice-to-have capabilities (43 features: │
│ │ │ Sensor APIs, Bluetooth, NFC, AR/VR, etc.) │
└────────┴──────────────┴───────────────────────────────────────────────┘
I'm very open to feedback. This is a sincere attempt to quantify vendors' PWA support.
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.
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.
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)
They’re the advertiser-focused company. Bluetooth and NFC aren’t being exposed for developers first.
Chrome APIs and Electron crap, and then everyone complains about Microsoft.
I have no desire for random websites to have that much access to my phone.
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?
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.
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."
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.
- 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.
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
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.
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.
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.
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
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.
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).
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.
That's where they burry all bodies.
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.
Nested scrollbars! Horizontal and vertical scroll!
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.
you can disable all those "features"
unless it means having the webpage itself render in VR and not just an isolated model
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)
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.
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.
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.
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.
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.
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.