Hacker News new | ask | show | jobs
by mort96 86 days ago
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.

2 comments

> 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.
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.
> Let Google dominate the web

No thanks

> 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.

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.
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.

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…