Why can Kagi's Orion browser support extensions on iOS? I recently switched from Firefox because lack of uBO caused huge beef for me and have zero regrets. I'm not paying for Kagi's search service (happy enough with DDG for the majority of my searches), but I can really appreciate their business model and mission (they seem genuine afaict).
Orion is built on webkit, both on desktop and mobile. It's possible to build WebExt support into a WebKit browser, as they've done.
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).
It would be interesting to see how Mozilla approaches implementing Gecko on iOS, with how the engine stripped support for embedding years ago (prior to which they could’ve used an approach similar to that seen in Camino[0]).
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).
This would currently be against the App Store guidelines, which do not permit the use of a third party browser engine. Also, Firefox has ProMotion support.
I thought Firefox on Android already did something similar to embedding, via GeckoView? The issue with embedding seemed to be that Mozilla really hated having complaints that their APIs were very unstable and kept breaking. In contrast, the IE embedding solid APIs were more stable (because they were also more limited, as I understand it).
Interesting, I always thought the holdup was that third party things used in-app were expressly forbidden because they're not vetted by the app store onboarding process (in addition to the requirement of using webkit). Didn't occur to me that webkit could be extended to support webext either.
Yeah, Apple likes to say that (and reject apps for violating that rule!), but then there's also things like Linux x86 userspace emulators in the app store that can run unmodified ELF binaries downloaded via curl from any random website...
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".
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.
Not sure what “userspace emulators” you're speaking of, but the apps I tried, for running a programming language (for education purposes) are rubbish due to limitations (you can only interpret, you can't compile). 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.
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.
I've linked one (iSH) in my comment. It really does run most completely unmodified x86 binaries for Linux, including CPython and Java.
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.
There's long been a grey area for downloading new program logic as e.g. Javascript—the distinction between content and program can be rather fuzzy—and IIRC they made an explicit exception years back for certain categories.
Historically, yes. Apple used to be a lot stricter about these things. But they have loosened up over the years.
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.
Browsers on macOS can use custom rendering engines. On iOS, they have to all use Apple's provided version of it (which does not support WebExtensions by itself), so the two are not comparable at all.
WebExtensions are (or at least can be) ultimately just a weird type of HTML+JS app, as far as I understand, so I suspect it's possible to run that in one WebView context on iOS and bridge the required APIs between the extension and browser context using content scripts.
