9 ms·

You're not allowed to provide your own web render engine at all. The JIT issue was solved a couple versions of iOS ago - embedded webviews now get JIT just like

by zwily 10y ago

You're not allowed to provide your own web render engine at all. The JIT issue was solved a couple versions of iOS ago - embedded webviews now get JIT just like Safari.

DonHopkins 10y ago
It's my understanding that only embedded WKWebViews are allowed to enable the JIT compiler, but not UIWebViews (or in-process JavaScriptCore engines). WKWebView is an out-of-process web browser that uses IOSurface [1] to project the image into your embedding application and IPC to send messages. So WKWebView's dynamically generated code is running safely firewalled in a separate address space controlled by Apple and not accessible to your app, while older UIWebViews run in the address space of your application, and aren't allowed to write to code pages, so their JIT compiler is disabled. Since it's running in another process, WkWebView's JavaScriptEngine lacks the ability to expose your own Objective C classes to JavaScript so they can be called directly [2], but it does include a less efficient way of adding script message handlers that call back to Objective C code via IPC [3]. [1] https://developer.apple.com/reference/iosurface https://developer.apple.com/reference/iosurface [2] https://developer.apple.com/reference/javascriptcore/jsexport/ https://developer.apple.com/reference/javascriptcore/jsexpor... [3] https://developer.apple.com/reference/webkit/wkusercontentcontroller/1537172-addscriptmessagehandler?language=objc https://developer.apple.com/reference/webkit/wkusercontentco...
eslaught 10y ago
> You're not allowed to provide your own web render engine at all. Is that true? I understand the security argument against JITs, but I don't see why it would be objectionable to run a copy of e.g. Gecko if you excluded the JS JIT component. (Of course you would never actually do that. But I'm trying to tease apart the separate arguments and see if they're actually connected.) It seems to me that the root cause for this is all the JIT. If the JIT in iOS has to be exposed via IPC for security (as claimed in a sibling comment) it's simply not going to be a win to try to use it in combination with a separate rendering engine, if it's even possible at all.
- st3fan 10y ago
  > Is that true? It is. Mozilla has an iOS port of Gecko. It runs well, even without the JIT, but we are not allowed to use it.
  - Ezhik 10y ago
    Is that OSS? I'm sure people would love to try it even if it involves sideloading and such.
    - st3fan 10y ago
      Pretty sure all the changes are in mozilla-central. https://hg.mozilla.org/mozilla-central/file/tip/embedding/ios https://hg.mozilla.org/mozilla-central/file/tip/embedding/io... Sorry I dont know where we keep the build instructions.
- bzbarsky 10y ago
  You're not allowed to ship a interpreter that interprets code that doesn't come from insider your app. So you can maybe ship Gecko + SpiderMonkey, as long as you only run JS that's part of your app. But if you want to run JS from a website (or indeed any code from anywhere), you're not allowed to do that on iOS. I haven't checked whether it would be OK to ship a browser engine that doesn't support JS at all, but that's a fairly academic question anyway.
  - st3fan 10y ago
    > You're not allowed to ship a interpreter that interprets code that doesn't come from insider your app. That is not true. Many apps do this. Games have been doing this for a decade. It is not a problem to do this. Apple has never made a big deal of that. Only if you are trying to build a shadow app store.
    - wvenable 10y ago
      Games interpret code that's shipped with the app. You cannot create an app which downloads code off the Internet (for example) and executes it.
therealmarv 10y ago
take a close look at Opera Mini ;) (they are doing Server rendering)

by zwily 10y ago

You're not allowed to provide your own web render engine at all. The JIT issue was solved a couple versions of iOS ago - embedded webviews now get JIT just like Safari.

DonHopkins 10y ago

It's my understanding that only embedded WKWebViews are allowed to enable the JIT compiler, but not UIWebViews (or in-process JavaScriptCore engines). WKWebView is an out-of-process web browser that uses IOSurface [1] to project the image into your embedding application and IPC to send messages. So WKWebView's dynamically generated code is running safely firewalled in a separate address space controlled by Apple and not accessible to your app, while older UIWebViews run in the address space of your application, and aren't allowed to write to code pages, so their JIT compiler is disabled. Since it's running in another process, WkWebView's JavaScriptEngine lacks the ability to expose your own Objective C classes to JavaScript so they can be called directly [2], but it does include a less efficient way of adding script message handlers that call back to Objective C code via IPC [3]. [1] https://developer.apple.com/reference/iosurface https://developer.apple.com/reference/iosurface [2] https://developer.apple.com/reference/javascriptcore/jsexport/ https://developer.apple.com/reference/javascriptcore/jsexpor... [3] https://developer.apple.com/reference/webkit/wkusercontentcontroller/1537172-addscriptmessagehandler?language=objc https://developer.apple.com/reference/webkit/wkusercontentco...

eslaught 10y ago

> You're not allowed to provide your own web render engine at all. Is that true? I understand the security argument against JITs, but I don't see why it would be objectionable to run a copy of e.g. Gecko if you excluded the JS JIT component. (Of course you would never actually do that. But I'm trying to tease apart the separate arguments and see if they're actually connected.) It seems to me that the root cause for this is all the JIT. If the JIT in iOS has to be exposed via IPC for security (as claimed in a sibling comment) it's simply not going to be a win to try to use it in combination with a separate rendering engine, if it's even possible at all.

st3fan 10y ago
> Is that true? It is. Mozilla has an iOS port of Gecko. It runs well, even without the JIT, but we are not allowed to use it.
- Ezhik 10y ago
  Is that OSS? I'm sure people would love to try it even if it involves sideloading and such.
  - st3fan 10y ago
    Pretty sure all the changes are in mozilla-central. https://hg.mozilla.org/mozilla-central/file/tip/embedding/ios https://hg.mozilla.org/mozilla-central/file/tip/embedding/io... Sorry I dont know where we keep the build instructions.
bzbarsky 10y ago
You're not allowed to ship a interpreter that interprets code that doesn't come from insider your app. So you can maybe ship Gecko + SpiderMonkey, as long as you only run JS that's part of your app. But if you want to run JS from a website (or indeed any code from anywhere), you're not allowed to do that on iOS. I haven't checked whether it would be OK to ship a browser engine that doesn't support JS at all, but that's a fairly academic question anyway.
- st3fan 10y ago
  > You're not allowed to ship a interpreter that interprets code that doesn't come from insider your app. That is not true. Many apps do this. Games have been doing this for a decade. It is not a problem to do this. Apple has never made a big deal of that. Only if you are trying to build a shadow app store.
  - wvenable 10y ago
    Games interpret code that's shipped with the app. You cannot create an app which downloads code off the Internet (for example) and executes it.

therealmarv 10y ago

take a close look at Opera Mini ;) (they are doing Server rendering)