While I definitely prefer FF and Android, I can support the notion of Mozilla integrating extension support into WebKit on their iOS version of FF. But it would take a lot of effort to do that, and Firefox for iOS is ultimately just totally separate from any other Firefox (whereas Android and Desktop Firefox share the same innards).
I guess they could take the approach of drawing the whole screen themselves but that’s going to make Gecko-based Firefox for iOS feel noticeably worse than the current WebKit/UIKit version in terms of responsiveness and such and might require some legwork to properly support VRR on 120hz iPhones (which is critical for battery life on those models).
At this point it's just a polite fiction, maintained jointly by Apple and app developers, that allows Apple to maintain a somewhat straight face when saying things like "you can't download third-party code at all" or "all code extending app functionality must be downloaded through our designated mechanism".
iSH is one such app, this blog post is very interesting: https://ish.app/blog/default-repository-update
Given the current regulatory scrutiny of their app store, I believe they just don't want to open yet another can of worms by rejecting "browsers" (which are really WebKit wrappers) for injecting third-party JavaScript into all web pages displayed within them, even though by their own rules, they arguably totally should.
Even if what you're saying is true, businesses that can't afford a ban from the App Store, can't afford to bend the rules. If Mozilla developed Firefox for iOS, with its engine, and Apple banned it from the App Store, the consequence would be millions of dollars going down the drain. And Mozilla would let their current users down, too, since the current Firefox for iOS is somewhat useful.
aShell [1] is very similar. It takes another approach – it compiles POSIX C source code to WASM and runs that using iOS's JIT-enabled web engine, which gives it much better performance than x86 software emulation. There's another one that uses lldb to interpret LLVM IR. In other words, if Apple doesn't want that type of app, they sure have been explicitly enabling the use case for a long time now.
> And the restrictions are mostly in place; otherwise, for example, there would be apps that allowed you to download torrents, or do other forbidden activities.
App store reviews don't exist to "prevent forbidden activities" in the legal sense; they are there to maintain their walled garden ecosystem financially, as well as protect their platform and products from reputational or legal harm.
The issue of legality and passing the App Store review process are largely orthogonal: Just like you can already do plenty of illegal things using stock iOS (e.g. writing threatening emails, downloading copyrighted material using WebTorrent etc.), you can do infinitely many legal things using Turing-complete computing as enabled by first and third party apps on iOS.
Now if you start offering an app that features a big button labeled "click here to dynamically load software facilitating copyright infringement", and Apple distributes it in their App Store after having reviewed it, that could get them into a tricky situation; offering a full-featured browser or OS emulator very likely doesn't, given that Google has been allowing these types of apps in their Play Store for more than a decade now.
Back in the day, they were removing stuff like scripting apps. They sent warnings to the devs of Pythonista, forcing them to do things like [remove file-opening support](https://mygeekdaddy.net/2014/06/17/working-around-apple/). And they infamously removed iDOS (a DOSBOX port).
Now they're much more loose and allow things like iSH and so on. It is still a little bit of a gray area for arbitrary decisions by Apple, though.
