This is made all the worse by the embarrassing bugs in Safari. Apple broke IndexedDB in the current stable Safari and isn't in any rush to fix it (see https://news.ycombinator.com/item?id=27509206). Safari updates are so infrequent that developers will have to include workarounds to this issue for years.

It's been fixed on master for over a month, but it hasn't been included in any of the Safari releases that have come out since then. When someone asked the Webkit engineers when we can expect a fix, their response was "Apple does not comment on future releases." https://bugs.webkit.org/show_bug.cgi?id=226547

If I asked you to imagine what you could do to sabotage the web, it would not look very different than what Apple is currently doing. Add "support" for modern web features but then actually subtly (or not so subtly in this case) break them on a regular cadence. To be clear, I don't think the Webkit team is doing this on purpose, but the effects on the web are still the same.

Perhaps it's because, to the user and the government, the "chrome" around the browser (bookmarks, experience, branding) is more important than the engineering details underneath, which most users don't care about. And governments, seeing other browsers are allowed but they have to use some similar plumbing, don't really care as the branding and sync and all that is different.

To them, it's the same reason why Apple might say you have to use the system Button instead of making your own Button, or use the system way of handling Graphics instead of making your own way of handling Graphics, use the system WebKit instead of rolling your own WebKit. That's a harder nut to define.

I honestly don't think more than 5% of users give a rip on what their browser internals are, if not less.

If we are going by that analogy, to governments the “chrome” is important when the “pipes” underneath are a common resource it regulates.

I don’t think govs regulating the implementation of anything in the OS is a good idea, but we could at least expect some wrist snapping to unlock the situation.

Has someone perhaps tried making a browser on iOS while sandboxed (aka. without JIT, and only sideloadable of course)? My understanding is that interpreted JS execution has abysmal performance and battery life characteristics, and given that Apple only entrusts themselves to run arbitrary code (since third-parties could just RCE themselves any bypass app store review otherwise) they can't allow other browser engines to use the JIT entitlement - it would look like they were intentionally handicapping the performance of other browsers.

The restrictions on JIT aside, my understanding is that there's also a separate rule that you can't have any web browser engine except the system version of WebKit.

Well, yes, but i'm trying to make a case for why Apple would want to prevent other browser at all - that being how it would look like Apple is intentionally handicapping other browsers by not letting them use JIT, raising less-explainable antitrust concerns.

One explanation could be that Apple doesn't want an "electron situation," where every app comes with it's own fully-loaded web browser, is a memory and CPU hog, and a security risk if the app is out of date. Like is currently happening on PCs.

With WebKit, its update once, secure all apps everywhere.

I'm curious if FirefoxOS had gone differently if Apple and others would've considered supporting a native-web approach for apps. (Albeit also tied to only one or a few blessed HTML and JS engines.)

That was the Apple party line when the iPhone was first released – the only Apple-blessed way to build iPhone applications was to build mobile-friendly web applications. There was a backlash – everybody complained and demanded native applications; the App Store was opened the year after.

https://9to5mac.com/2011/10/21/jobs-original-vision-for-the-...

IIRC FirefoxOS did it differently. Apps were local bundles of web tech. Not only pinned links to open a browser.

Apple was in critically bad place when windows dominated with Internet Explorer, and Adobe with its apps. These two companies dictated where the users would be, and Apple had to beg them to play nice.

The iPhone was a whole new platform where Apple had 100% power on where it could go; opening the door to third party browsers to bring their domination to the platform from the start must have been seen as suicidal.

Another explanation, less popular, is that Apple restricting to WebKit actually helps foster browser competition at the moment.

Let me explain. Right now it's WebKit vs Blink (Chrome and all Chromium-based Browsers, including Brave, Vivaldi, Opera, Edge, etc.). If Blink were to be allowed on iPhones... you'd see Chrome become even more dominant. Firefox is dying on PC, has less than 1% mobile share, and is no competition in this case.

Requiring WebKit is what prevents an even greater Chrome monoculture.

It is totally about preventing alternatives to the App Store.

That's the rule, but you have to wonder why. They don't get more money just because Google can't spend their own development resources on targeting and validating Blink/V8 for iOS.

90% of the revenue is games. Mobile Chrome would only need to support idiosyncratic Unity and Unreal web targets for a significant chunk of that revenue.

You can decouple the browser engine from JS, e.g. use Apple JS core with Chromium/blink