The solution to this is simple, Apple needs to make their browser usable enough that people don't go to extremes such as packaging entire browsers with their code. In many cases Safari's Javascript engine will even beat Chromium's engine.

Android allows any browser engine you like (even Webkit if someone would manage to compile it) and people don't generally do nonsense this on Android. I don't see why the situation would be any different here. The reason is simple: the web view API is easy to use, automatically updated, and backwards compatible.

As another benefit, devices that have fallen out of support may receive updates for browsers, making them usable again.

Developers will package browsers in their code as a way to spy on users with fewer restrictions, not because Safari is unusable.

That being said, I returned my first and last iPhone after realizing that Firefox on iOS couldn't run the NoScript extension.

It is frankly shocking that Apple has managed to go this long while blatantly contravening the precedent set by United States v. Microsoft Corp., and I'm glad the EU is finally taking a stand on that front.

> Developers will package browsers in their code as a way to spy on users with fewer restrictions, not because Safari is unusable.

I've also seen developers cling to particular versions of Electron simply because their app is so brittle that its behavior on different versions of Chromium is not consistent or even breaks, which is frankly ridiculous. If it doesn't run on the latest version of Chrome at minimum it shouldn't be shipped.

> that people don't go to extremes such as packaging entire browsers with their code.

The app dev will simply use framework X and because of that it includes some version of some browser engine.

And then people are going to complain about not getting JIT access is unfair advantage to safari, but then if they do get a JIT entitlement they are going to slack on patching vulnerabilities...