> They can use their internal render engine. What they can't use is their Javascript framework because a modern JIT requires taking compiled javascript code in memory and marking it as executable
> You can even ship a custom Javascript engine on iOS if you disable JIT, it will just be slow.
Wouldn't this mean that Mozilla could theoretically ship "real" Firefox (Gecko/XUL/SpiderMonkey) on iOS after the SpiderMonkey wasm port[0][1] lands?
> Instead of working directly on the machine’s memory, the JS engine puts everything—from bytecode to the GCed objects that the bytecode is manipulating—in the Wasm module’s linear memory.[2]
Outside of sideloading, probably not. The rule Apple has isn't "only we use JIT", it's "only we load code".
The lack of third-party JIT entitlements (outside of a debugger entitlement in iOS 14.0 thru 14.2) is downstream of the prohibition on loading code. For the record, "loading code" implies that the code is coming from somewhere other than the current app bundle. Embedded JavaScript, Python, Mono, Flash, or any other interpreters running code that ships with the app are fine. (At one point, Apple actually threatened to ban these. It was concommitent with "Thoughts on Flash".) However, running code by any means from any other location - a third-party server, or even user-selected files - is very much considered malicious behavior by Apple.
The contours of this rule are particularly strange, though. It's not just a pure ban on all third-party apps that interact with third-party code. You're allowed to have third-party browsers. But they have to use Apple's WebView control to get access to a browsing engine. Yes, you can compile a no-JIT build of Gecko, but Apple will never approve it. In fact, Apple goes so far as to even prohibit projecting new web APIs through the WebView interface. (I have no idea how they're going to apply this rule to Safari extensions in iOS 15.)
Of course, Apple also wants to sell iPads as computers, which means that eventually someone is going to want to program on their iPad. This has resulted in quite possibly the strangest rule exception I've ever seen on the App Store. You're allowed to load code if it's code that the user can see and modify. The explanation being that these aren't "code loaders", now they're "learn to code apps". So, e.g. Swift Playgrounds and third-party JavaScript or Python REPLs are perfectly fine. But, of course, all of that has to run at interpreter speed.
Side note: Apple is hilariously inconsistent with this rule, when it comes to emulation. Riley Testut proposed a ROM whitelist on GBA4iOS which App Review said they were OK with, but then changed their mind on by the time it was submitted to the App Store. iSH - an app that emulates x86 Linux binaries - was approved, pulled, appealed, and then re-approved under the "learn to code" exception. iDOS 2 - an app that does the same thing but with DOS apps - was approved, and then pulled with a rejection letter that strongly implicates iSH.
> You can even ship a custom Javascript engine on iOS if you disable JIT, it will just be slow.
Wouldn't this mean that Mozilla could theoretically ship "real" Firefox (Gecko/XUL/SpiderMonkey) on iOS after the SpiderMonkey wasm port[0][1] lands?
> Instead of working directly on the machine’s memory, the JS engine puts everything—from bytecode to the GCed objects that the bytecode is manipulating—in the Wasm module’s linear memory.[2]
[0]: https://spidermonkey.dev/blog/2021/07/19/newsletter-firefox-...
[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1701197
[2]: https://bytecodealliance.org/articles/making-javascript-run-...