Apple requires browsers on iOS to use the same rendering engine as Safari, but would it allow a browser to use a different JavaScript engine? Or is this a loophole that Apple didn't forsee that they will be closing in the future? Are the rendering engine and JavaScript engine so separated that you could use the Safari rendering engine, but a different JS engine?
There's a software-level rule that forbids JIT engines by never allowing apps to mark pages as executable. According to this rule, you could run Chrome on iOS now. But there's also a policy level rule:
> 4.7 HTML5 Games, Bots, etc.
> Apps may contain or run code that is not embedded in the binary (e.g. HTML5-based games, bots, etc.), as long as [...] the software [...] only uses capabilities available in a standard WebKit view (e.g. it must open and run natively in Safari without modifications or additional software); your app must use WebKit and JavaScript Core to run third party software and should not attempt to extend or expose native platform APIs to third party software
That wording is kinda fuzzy about the distinction between the old UIWebView and the new WKWebView, which are very different.
Note that you can use either UIWebView and JavaScriptCore in your own app, which doesn't JIT, --OR-- WKWebView and its JavaScript interpreter, which does have JIT enabled, but runs in a separate process (not unlike Microsoft OLE out-of-process servers). Apple allows their own trusted apps to JIT (i.e. Safari, which is the same as the WKWebView engine that runs in a separate process). But UIWebView with JavaScriptCode that runs in your app are not allowed to JIT.
You can extend the JavaScriptCore interpreter used by UIWebView (which you can also use standalone without a UIWebView) with your own native Objective C code, that it can call directly via a JavaScript/Objective C bridge. (See NativeScript for example.) But that's impossible to do with WKWebView, whose JavaScriptCore (or whatever it is -- I'm not sure it's the same framework but it might be), because it runs in a different process. All you can do is to send messages (like JSON events or whatever) via IPC over Mach ports, not call your own code directly.
You could use the XCode linker to embed your JS/WASM code in the binary as a read-only resource/section, and then run it using JIT-less V8. Interpreted code is generally more compact than a native ISA like ARM64, so this could be useful in order to reduce app size.
It needs to be embedded in the binary, because code that is not so embedded has different rules applied to it. So, it has to be done either in the compiler (e.g. as compile-time const arrays, which will then be part of the rodata section) or in the linker; the latter is arguably a bit easier.
I think that should be possible. The main restriction seems to be
2.5.6 Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript.
Using V8 to execute JS without 'browsing the web' sounds okay.
And perhaps also this, although it is not clear to me whether downloaded JS scripts are considered 'code':
2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps. [...]
As far as I know Apple doesn't require browsers to use the same rendering engine as Safari. It's just that so far any rendering engine + JS engine required a JIT to make it performant. And because a JIT is not allowed because apps are not allowed to write to executable memory. That's why the 3rd party browsers all used the same rendering engine as Safari.
The app store rules disallow other rendering engines: 2.5.6 Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript
Before WKWebView, even the Safari-based UIWebView didn't JIT JavaScript. Chrome for iOS was released years before WKWebView was added, so a lack of JIT in their own JavaScript engine would not have made a difference.
