And the user doesn’t even notice.

What's the problem? The only people that complain about it are some web devs and companies that would love to get their grubby data collecting hands on your device's battery and gyroscope data.

> The only people that complain about it are some web devs and companies that would love to get their grubby data collecting hands on your device's battery and gyroscope data.

Why would allowing more browser engines have even the slightest impact on that? Those are APIs available to all native apps they have literally nothing to do with underlying browser engines.

May I remark that you're not answering the question?

> Those are APIs available to all native apps they have literally nothing to do with underlying browser engines.

Except that Safari doesn't expose them while Chrome wants to (or already does), offering Google more fingerprinting capabilities. Native apps don't send data to Google, Chrome does.

Safari absolutely exposes gyroscope data. Not sure where you’re getting the idea that it doesn’t.

The problem is that Apple is slow to implement useful web standards. I don’t think the battery API is all that useful either but WebRTC is incredibly useful and it took Apple years to catch up. If they had meaningful competition in the iOS browser space they’d have more incentive to try.

Native apps go through App Store review, and can be permanently banned for misuse for tracking purposes without express user consent.

Allowing more browser engines would require granting those engines your battery and gyroscope data in order for them to display per-site permission dialogs.

This problem is unique to browser engines and no other kind of app, as browser engines are uniquely the only kind of app that needs this sort of permissions-granting per-site passthrough.

Apple likely does not consider it interesting or relevant to their users to invest in validating the security models of third-party browser engines for their adherence to App Store standards, nor in providing a public API for third party engines to do so, and so closes off the entire problem space by refusing third-party engines altogether.

> Allowing more browser engines would require granting those engines your battery and gyroscope data in order for them to display per-site permission dialogs.

...a process which could be reviewed as part of the App Store review process.

There isn't really any difference here. If your app reads gyroscope data App Store review will (theoretically!) make sure you're not doing anything nefarious with it. They could just as easily verify whether a browser passes data through correctly.

Correct: they are not doing something that is possible to do. What benefits to their users result from that choice?

(I’m aware of what drawbacks result from it, but that’s been explained to death in a thousand replies in a hundred posts about this already, so no need to derail into them here.)

One benefit that immediately comes to mind is the ability to protect yourself against a major security flaw in Safari:

https://safarileaks.com/

Apple did issue a fix after a few weeks but with no alternative browser engines the only alternative was “don’t use the web on your iPhone”, which is absurd.

Other user benefits might include better performance, more capabilities (it took Apple years to implement WebRTC, for example) and in general more competition that might spur Safari into becoming a better browser.

The other browser engines have other security CVEs. Switching engines on the backend does not materially reduce the total attack surface for vulnerabilities for any given everyday user. Using security vulnerabilities as a primary condition of existence also leads to the introduction of engine oversight, review, and adamant “update or be removed” policy enforcement upon third parties, all of which who will complain endlessly in the press about the draconian App Store policies they would be subject to. I expect a better case will need to be made to convince Apple.

You asked:

> What benefits to their users result from that choice?

But now we've gotten to

> I expect a better case will need to be made to convince Apple

Those aren't nearly the same things. Of course it's difficult to convince Apple, it isn't in their interests.

You make the case that it’s to the benefit of their users to allow multiple browser engines. I am personally not convinced by your case, for the reasons stated above. I do not expect Apple to be convinced by your case either.

You may choose here to strengthen your argument, but your declaration that it’s hopeless to do so is of no help in that regard. If you wish to continue, I’m willing to listen.

I complain about it as a user, and I take my money to android (reluctantly) as a result. I would love to run apple hardware for my phone, but their over the top control over the whole closed wall ecosystem is why I don't.

Good for you, but it doesn't tell me why allowing only a single HTML rendering engine on iOS is a problem.

> What's the problem?

If you're not asking rhetorically, that's one of the primary subjects of this report.

I've read the first 25 pages or so, and the question is not answered there.

One takeaway that is important, IMO, is this one:

> Without browser diversity, a single company’s influence can shape the internet.

That would be a problem if iOS accounts for a large majority of all http traffic. That, however, is not the case. If there's one platform that accounts for the large majority of http traffic, it is Chrome. It's estimated market share is 65%. Its derivates take 10% more.

Allowing Chrome on iOS will slowly but surely obliterate Safari. Firefox' market share is a joke to begin with (and I say this as a lifelong Firefox user; I even use Firefox on iOS). Browser diversity ends when Chrome arrives on iOS, and it would end the limited privacy we have on iOS, unless Apple would really tighten the rules.