iOS404
ios404.com
ios404.com
This is a good example of how the chromium monoculture hurts the web. It ends up being Google's way or highway.
EDIT: You can filter by features that both Firefox and Chrome support by tapping the Chrome icon. This takes the list from 63 entries to 29
This also would of course be even nicer if you could define any browser as the "target" (e.g. compare Chrome -vs- Firefox) but then that wouldn't serve their very nice domain purchase as neatly.
Should iOS adopt [feature] because Chrome has it, or why else is it on the list? What benefits am I missing as a user?
As a mainly desktop Firefox user, any time I have a web bug my developer colleagues asks me to try Chrome instead because they only develop and test in Chrome. I would say if we care about standards and an open web we should not cater so much to Chrome's whims and wishes…
In practice, I've never missed an API on Safari for building websites that customers ask for. I have missed Chrome dragging it's feet on CSS properties like Snap Points or backdrop-filter.
The difference in culture couldn't be any more apparent, with this website having a complete disregard for users as it's actual content is just rendered into an image, not available to basic web browser functionality like copy and paste.
The text is actual text.
I must have disallowed selecting for the swiping feature to work. Definitely something I should look to revert or allow for copying buttons.
While the visualization is cool, I hope some of these will remain "not found" indefinitely. Just because we can stick everything into a web-spec, doesn't mean we should.
Rich companies such as Epic, complaining about a 30% cut can cry me a river. Lock iOS down as much as possible and restrict/sandbox the web.
iOS is the only internet connected computer I’ve had that didn’t get malware and/or a virus at some point. Unless you consider an Xbox/PlayStation a computer.
https://medium.com/online-io-blockchain-technologies/the-evo...
Native apps have a much higher level of friction at multiple points that helps balance the higher level of access they get.
These APIs are also much more restricted than their proprietary-ecosystem equivalent.
Overall, web apps having access to these features in Chrome are an order of magnitude safer than platform-specific apps.
As for the 30%, How long do you think it would be before Chrome decides to monetize their web apps? The Manifest v3 story was a hint, maybe not everyone got the memo.
Personally, I've found a bunch of these super useful, as user and a developer. Being able to use tools like https://www.espruino.com/ide/ to play with hardware straight from the web is amazing.
You don’t need to do that, you can just right-click the app and choose “Open”.
The browser (agent) is a native app designed to allow users to access and navigate web resources (we call them pages or documents). Pages can be styled (CSS) and made interactive (JavaScript).
When one wants to create an experience which goes beyond the scope of the browser, one builds another native app that is able to leverage the needed resources. A dedicated native app can embed a browser (e.g. webframe) or consume web resources through other protocols. A native app can also request access to hardware resources via the OS.
[1] https://open-web-advocacy.org/walled-gardens-report/ [2] https://changelog.com/jsparty/316#t=00:25:59.26
You say the web is more mature, to which I reply that this is the same circumstance as leaving one browser to become dominant (which we already did). In a perfect world, having a closed option would be "one of the options on the table" but for the majority of users this is not the case.
Introducing WebUSB (or any of the more exotic features on the list) will not help us towards an open platform. On the contrary, it will only worsen the dependence on a handful of corporations that can afford to invest to build a browser. Remember, even Microsoft couldn't afford to continue working on their own engine.
As a developer, I care very deeply about being able to make my apps and experiences available to "all the platforms" but shifting the cost of compatibility into userland is not a long term solution. Just put yourself in the shoes of a traveller, struggling to pay for their last-minute plane ticket at the gate but being greeted with "Sorry, our checkout page doesn't work on your browser/device". This is not the way.
Chrome becoming the dominant browser is also concerning, and they will have to be held to a much higher scrutiny by us and policy makers to ensure they have users best interest at heart [3].
> shifting the cost of compatibility into userland
What do you mean by this?
> struggling to pay for their last-minute plane ticket at the gate but being greeted with "Sorry, our checkout page doesn't work on your browser/device". This is not the way.
I agree! This is exactly why we can't depend on one organization to dictate what's allowed and disallowed on that platform. On iOS, think about how long it took Apple enabled Apple Pay support for non-safari browsers even though they all had to be WebKit-based.
[3] https://open-web-advocacy.org/walled-gardens-report/#the-chr...
I'm Shalanah. I made iOS404.com.
A couple of feature notes:
- Compare to other browsers by clicking on the Chrome icon to switch to FF for Android or Safari Desktop (or a combo).
- Select or deselect specification by clicking on the filter icon.
On what's to come: I'm looking to add MDN features next. There are wayyyyyy more missing iOS features there.
Thanks! -Shalanah
For example this other post is older (6 hours ago), with less points (70) and less comments (34), and yet it shows on top 12 of HN:
12. Show HN: a Rust based CLI tool 'imgcatr' for displaying images (github.com/silinmeng0510)Because with it, we can offer users to hold their data natively on their devices. Instead of storing everything in the cloud.
So far, I think only Chrome on the desktop supports it. Here is a nice demo:
https://googlechromelabs.github.io/text-editor/
A text editor that works just like a native application.
https://github.com/mozilla/standards-positions/issues/154
https://github.com/WebKit/standards-positions/issues/28
Neither Mozilla or Webkit are satisfied that the proposal is safe by default, and contains footguns for the user that can be pretty destructive.
> Colleagues and I have discussed this and don't see a way to grant write access to the end user's local file system in a way that safeguards the end user's interests.
https://developer.mozilla.org/en-US/docs/Web/API/File_System...
https://webkit.org/blog/12257/the-file-system-access-api-wit...
It's able to support this because the 'file system' is scoped specifically to that origin, and doesn't allow access to any aribtary location on the file sytem, just like iOS.
If Apple made arbitrary file access work for apps [1], surely they could make it work for Safari. But apps pay 30% and websites don't, so it's easy to conclude why they don't want to.
[1] https://developer.apple.com/documentation/uikit/view_control...
1) When loading a file, nothing needs to be different from the already available upload functionality. The user picks the file to load.
2) When saving a new file, nothing needs to be different from the already available download functionality. The user picks the name and the place to save it.
Only after 1 or 2 have already happened can the page request to update the file. With the same name and location. In this case, the user gets a prompt that explains the risks and asks the them to confirm the update.
https://github.com/mozilla/standards-positions/issues/154#is...
But very cool site. And I definitely think Safari should have some of these! It's a bit cruel on them! Hahaha! :)
I feel like they lack a lot in the QA side of things, it doesn't feel very polished.
I'd be more accepting of Safari if it would be more polished and had a better release cycle (it's also the last major non-evergreen browser), all the next gen features are good sure, but not a replacement for those problems.
So don’t only focus at what isn’t here yet.
It's a problem when Apple refuses to implement standards because it hurts their 30% cash cow monopoly, but most APIs on that site aren't that.
It’s amazing something so short-lived had such an impact.
Yes, Apple has dragged its feet on standards but things that Chrome just decided on by itself are not standards.
A number of the partially implemented (on iOS) things (like clipboard or volume) have legitimate privacy concerns or UX concerns. I don’t want a website to read my clipboard, I don’t want a website to change my volume.
There are some more legitimate looking things but a number of those are not part of the spec according to this very website.
I’ve said for years that Chrome is closer to IE in writing their own standards and Safari is closer to IE in conforming to the standards. But blanket “Safari is the new IE” statements are just silly and miss the forest for the trees.
Google is definitely not in the clear, but Apple's anti-competitive practices is much more damaging to the open web.
> Typically, cutting edge features are deployed by browser makers in their own engines first, then, using real world feedback over several years, eventual standards are created. No feature starts out as a web standard. – Walled Gardens Report, Open Web Advocacy [1]
Apple dragging it's feet will impact this, but Apple outright banning competing browser engines kills all progress. Having competing browsers on the platform will allow the market to decide what features are useful and what are not, and the standards can follow suit. I agree there are privacy concerns with some of the proposals (especially some of the ones by Google), but not having the choice of browsers is much worse for the open web.
At the moment, we just have to trust Apple has our best intentions by supporting/not supporting certain features and standards. However, we know from the work the Open Web Advocacy has done that this isn't true. The primary driver for both stifling progress on Safari and keeping browser competition out is the profits from the App Store [2].
[1] https://open-web-advocacy.org/walled-gardens-report/#mandati... [2] https://changelog.com/jsparty/316#t=00:25:59.26
If apple wants to treat the web like documents, that's fine, but then don't make it suck like an app. If a page is loaded, there is NO reason to randomly reload it because iOS deems it has been too long. Maybe it's a general problem with iOS killing apps in background, I don't care, it sucks.