rejhgadellaa

> Strange then that they routinely don't wait for and ignore any and all input from other browser vendors

It's not strange when you consider that other browser vendors sometimes flat out refuse or delay. The only option, then, is to just go ahead, spec, build and launch it, and let the market decide whether to push those vendors to reconsider.

"The Power of 'No' in Internet Standards"

https://www.mnot.net/blog/2026/02/13/no

"How Do Committees Fail To Invent?"

https://infrequently.org/2025/08/how-do-committees-fail-to-i...

But if the web engine you have to use is a) shitty and b) the same as everyone else (except slightly shittier [1]), how are you going to make it popular?

The browser engine is an important piece of the puzzle when it comes to getting people to switch browsers. If a site works faster or better on browser B, that's a reason to switch.

If Apple's WebKit engine doesn't allow you to do video calls, you could build that into your engine and actually compete.

Why would Google and Mozilla spend millions on developing and maintaining their own engines if they didn't think that it provides value, e.g. a competitive edge?

[1] In the past, Safari did get some features that other browsers on iOS didn't get, e.g. Being the default browser (you couldn't set Chrome or any other browser as the default until iOS 14(!), Nitro JIT (Safari was significantly faster than other browsers on iOS for 4 yrs), camera and microphone access (video calls only worked in Safari), Web Extensions, Apple Pay, Fullscreen API, Add to Home Screen (ironically)...

Right. So I don't know the costs of the hoops we need to jump through for our app to be granted a place on the app store. I'm not the guy who does the spreadsheets :). I do know that we've spent considerable time to make changes to pass app store review.

For example, our platform requires a subscription, but we can't link to the page where you subscribe anywhere. That means that if our FAQ page links to the subscribe page, and we have a link to the FAQ anywhere, we have to block that from happening. This isn't just extra work (to prevent users from ending up on that subscription page), it actually prevents us from offering users a way to subscribe or even change their subscription from within the app. This directly hurts our business model (subscriptions) and UX (users have to change their subscription by manually visiting our site in a browser).

All of this work means we either have to charge the user extra money (increased costs for consumers) or do less with the money we have (decreased value for the consumers).

I know this doesn't fully answer your question, but I hope it sheds a bit of light on what these extra costs are and how consumers end up paying for it.

>> If your app doesn't work for the wealthiest 50% of users, why go that route?

> Why doesn't business hire two teams? One for the amazing native-like PWA, and one for iOS?

You quote me, but missed the exact part where I already answered that question (I presume by accident ;)), so I'll just repeat myself:

> Yes. The web's winning feature is "it works everywhere". If your app doesn't work for the wealthiest 50% of users, why go that route? Making a desktop web app work on mobile, just for Android, is a lot of work. It needs to work on both iOS and Android to make it worthwhile.

For background, this piece by Alex Russell is worth reading:

Platform Adjacency Theory

https://infrequently.org/2020/06/platform-adjacency-theory/

The WPT graph shows failures for tests that fail in only one browser. So the accelerometer tests, for example, would need to pass in both Blink and Gecko for it to count as a failure on Safari's part.

> A feature that is shipped in a single browser is just that: that browser's non-interoperable feature.

AFAIK, the popover and/or anchor positioning APIs was standards before it shipped in more than one browser. (I will say that all three(?) of them agreed to build it)

> "it's a napkin scribble, not on any standards track".

Chromium/Blink have a process, and it's quite rigorous (precisely because they understand that they're pushing things, so they have a responsibility to make sure it's good):

https://www.chromium.org/blink/launching-features/

Building the same app for iOS, Android and desktop: up to 2-5 times the costs (for businesses, how they cover those costs depends)

App tax: 15-30%, which can drive the price for consumers up by up to 44%

https://open-web-advocacy.org/walled-gardens-report/#negativ...

> business hires three teams?

Yes. The web's winning feature is "it works everywhere". If your app doesn't work for the wealthiest 50% of users, why go that route? Making a desktop web app work on mobile, just for Android, is a lot of work. It needs to work on both iOS and Android to make it worthwhile.

> they all depend on full desktop browser to work (often due to sheer fact that they are complex apps that don't work well on mobile screens)

Gmail, Office, Docs - they all exist on mobile (as native apps). So it's not the complexity itself that makes it a problem on mobile screens. What does the native Gmail app do that the desktop web app doesn't?

> Android's market share is 68-70% worldwide.

Not in the wealthiest parts of the world, where the money is.

> if you break the app store monopoly, you can install chrome or firefox and do all the web-app-platform nonsense you want

Apple would also need to be forced to provide the APIs that browsers need so they can properly integrate with the OS (a lot of those APIs are private, currently), but good point, that would absolutely be one way to break this open.

> In other words, Apple has successfully prevented you from writing a web application

... by abusing their monopoly position on iOS (instead of competing).

Good outcome?

> Google often doesn't bother even with a spec.

I'm sorry, but that doesn't seem to be right. They have a process: https://www.chromium.org/blink/launching-features/

> I wouldn't really quote Alex Russel on anything related to standards

I disagree :)

...but it's getting late here, have to shut down :)

I thought this was obvious, but higher costs for building and maintaining an app (vs a web app) means higher prices for users. I think people would love to pay less, and would hate to pay more.

First of all: don't they? (honest question, I truly don't know if Africa has more PWAs compared to US/EU/etc)

Second: There are many reasons why businesses would opt for a native app. Notifications, for one (not available on the web on iOS until just a couple of years ago). Also, native apps allow for more tracking (whereas browsers are paranoid by default).

Third: A few years back, companies like FB, Google and Twitter all launched "Lite" versions of their apps, specifically targeted at Africa and other developing markets. They were all web apps (or wrappers around web apps). I will admit that this was years ago, and I have not checked if these Lite versions are still around and/or widely used.

> I care whether Apple would compete with Google, and they wouldn't.

They receive $20B a year from Google (search engine deal). Some estimates put WebKit/Safari's budget at $500M. That's a rounding error away from $20B of pure profits. I completely agree that Apple is not in it for the good of the web. They are in it for $20B a year.

And even if they wouldn't want to compete: fine. Let them give up. Make room for browsers that do want to compete (or at least, let them try).

> WebKit isn't a browser monopoly, it has less than 20% of the browser market share.

That monopoly on iOS is enough, though. The web has to work on iOS because the wealthiest users have an iPhone, and all they have is WebKit. I work at a place where most of our users are on mobile, and most of them are on iOS. So WebKit sets the bar for what we can do. In other words, Apple is in full control of what we are able to do. Building features for Android users is often not worth our time and money, so we just don't build it.

Funny you would say that. Because businesses and users have only one choice on iOS: native apps, because the web app isn't viable (and/or available) on iOS.

How is that irrelevant? Isn't it important to ask the question "why did this thing work on desktop, but not on mobile?"

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

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

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

Fair :)

No, because any browser can decide to ship a feature that it thinks is worthwhile. Users can decide which browser they trust to be their User Agent. The distribution model is open. You type a URL, you click a link. No single company in control.

> many of these are in fact not a standard according to W3C and should not be implemented in any browser until it is.

That's not exactly how standards work. A browser (or anyone) comes up with a spec, a browser can ship it (to test the waters in an origin-trial, to gain traction if they believe in it), and the standard (often) comes after the fact:

"Working Groups don't gate what browsers ship, nor do they define what's useful or worthy. [...] In practice, they are thoughtful historians of recent design expeditions, critiquing, tweaking, then spreading the good news of proposals that already work through Web Standards ratified years after features first ship, serving to licence designs liberally to increase their spread."

https://infrequently.org/2025/09/standards-and-the-fall-of-i...

> The people don't like apps built with web tech

Then why do most people spend > 90% of their time in a browser (or web-powered app) on desktop?

The web can be a competitor for the app stores, breaking that monopoly. It already did on desktop (where most users spend > 90% of their time in a browser)

And yes, you can write native apps in a lot of languages, but you can't choose how/where you distribute.

On the web, you can. It's built that way.

If a web app doesn't work on iOS, a business builds a native app instead. iOS is too important. So that fantastic native-like PWA never gets built in the first place.

Apple is not just holding back PWA on iOS, they're holding back the entire web everywhere.

Compare that with desktop, where web apps (maybe not PWAs, strictly speaking) are dominating: Gmail, Office/Docs, GitHub, Figma, you basically do everything in web apps.

And if you count Electron [1]: VSCode, Slack, Spotify, etc, etc.

[1] Importantly, Electron lets you bring your own (browser) engine. You can build a native app on iOS that is just a wrapper around a web app, but it has to run on iOS' WebKit, and is thus limited by what Apple deems worthy

Businesses tend to relay costs onto their customers (someone has to pay the bills).

- The app store tax

- The extra work of maintaining at least 2 separate apps (iOS, Android, optionally(?) desktop web app)

- Dealing with app store rules

Some of these are not just costs. I have experience with native apps that have to make things worse for users (compared to the web app) or risk getting booted off the app store.

> I don't think Apple is terribly interested in market share for Safari

Google pays Apple $20B a year because of the market share Safari has on iOS.

I'd call that "interest"

That's 10% of their turnover (and likely mostly pure profit, as they seem to spend a fraction of that on Safari)

First of all, features can be a standard without (full) FF and/or Safari support.

Second, Safari has a monopoly on iOS and controls what other browsers can support on the platform (that also usually means "less than Safari", because SF gets to support things first). They are in a unique position to hold back the entire web, even on other platforms. They're holding the standards hostage by not allowing the market to decide which features are important to them (and put pressure on Safari and FF to implement them)

Do you have a source link for this? I don't want to sound snarky, but this list doesn't make sense to me.

Offline support has been available (and buggy, YMMV) for a long time.

Web Push has been available since 16.4 (with a lot of caveats)

I haven't heard anything about installation (but I may have missed something)

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)