3 ms·

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 n

by est31 8y ago

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 https://developer.apple.com/app-store/review/guidelines/ https://developer.apple.com/app-store/review/guidelines/

0815test 8y ago
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.
- k__ 8y ago
  Also, to use the same engine for all platforms
- saagarjha 8y ago
  > 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. Or just read it from a file?
  - 0815test 8y ago
    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.
    - saagarjha 8y ago
      But this isn't code (at least, to the operating system)?
    - xsmasher 8y ago
      "The binary" in this context means the ipa (archive) that you send to Apple. They are making a distinction between downloaded data and data included in the archive, but using sloppy terminology.
- DonHopkins 8y ago
  That's a lot like what Unity3D used to do with Mono CLR byte code on iOS. But now it uses IL2CPP to compile it into C++.
DonHopkins 8y ago
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. https://www.nativescript.org/ https://www.nativescript.org/

by est31 8y ago

0815test 8y ago

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.

k__ 8y ago
Also, to use the same engine for all platforms
saagarjha 8y ago
> 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. Or just read it from a file?
- 0815test 8y ago
  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.
  - saagarjha 8y ago
    But this isn't code (at least, to the operating system)?
  - xsmasher 8y ago
    "The binary" in this context means the ipa (archive) that you send to Apple. They are making a distinction between downloaded data and data included in the archive, but using sloppy terminology.
DonHopkins 8y ago
That's a lot like what Unity3D used to do with Mono CLR byte code on iOS. But now it uses IL2CPP to compile it into C++.

DonHopkins 8y ago

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. https://www.nativescript.org/ https://www.nativescript.org/