7 ms·

My understanding is that the reason Chrome has to use the iOS webkit view is because that's the only way to get JIT javascript compilation working for apps subm

My understanding is that the reason Chrome has to use the iOS webkit view is because that's the only way to get JIT javascript compilation working for apps submitted to the app store. Does anyone have a sense of whether it would be possible to switch to Blink and V8 with a locally compiled and sideloaded version of the app? Would there be any benefit?

bad_user 10y ago
Before iOS 9 (or something) that JIT engine wasn't even exposed in the web view available for apps, so no matter what you did, you couldn't match the performance of Safari. On iOS browsers like Chrome and Firefox are basically unable to compete in terms of performance, web standards or features like browser plugins. So people that use them do so just to get sync. Of course Safari Mobile is decent nowadays, but that's not the issue.
- oatmealsnap 10y ago
  Yea, it was always an outdated version of WebKit.
  - JonathonW 10y ago
    Not outdated (it's always been the same WebKit version as used by Safari), but security restrictions on iOS (specifically, third-party iOS apps can't JIT-- the OS won't let apps without a specific entitlement execute from a writable section of memory) prevented in-app web views from using the same Javascript engine as Safari. iOS 9 eliminated that performance penalty-- it introduced a new kind of web view backed by an out-of-process renderer and JS engine, which, since it's Apple-blessed, doesn't have the JIT restriction. Third-party browsers updated to use the new framework can get the same performance as Safari.
    - gcp 10y ago
      Third-party browsers updated to use the new framework can get the same performance as Safari. But that framework is missing various things, such as content blocking. (That goes a long way to explain why there's both "Focus" and "Firefox" on iOS)
      - hendersoon 10y ago
        Exactly right. Lack of content blocking is why I don't use Chrome on iOS. I strongly prefer its UI and sync, but can't go back to seeing ads.
      - djrogers 10y ago
        > But that framework is missing various things, such as content blocking Not really - SFSafariViewController uses content blockers, autofill, etc. There's also WKWebView for those that want to implement their own content blockers and autofill engines. Curious why you'd want safari's content blockers to run inside chrome or firefox though? That's not how browser plugins work anywhere else, and it seems like if content blockers were forced in to 3rd party browsers there'd be a lot more angst over that decision. [1] https://developer.apple.com/library/ios/documentation/SafariServices/Reference/SFSafariViewController_Ref/ https://developer.apple.com/library/ios/documentation/Safari...
        bad_user 10y ago
        Extensions like 1Password work in Firefox and Chrome but not content blockers. I know because I tested both. Mozilla also made a statement about it: https://motherboard.vice.com/read/heres-why-firefox-for-ios-cant-block-ads-like-it-can-on-the-desktop https://motherboard.vice.com/read/heres-why-firefox-for-ios-...
        st3fan 10y ago
        1Password only works in non-Safari browsers if those apps include a less optimal SDK that provides a generic password filling conduit. It is not something that WKWebView automagically does. See https://github.com/AgileBits/onepassword-app-extension https://github.com/AgileBits/onepassword-app-extension
oatmealsnap 10y ago
That might allow Chrome Extensions on iOS, but it seems like a lot of work to make that happen.
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.
  - bzbarsky 10y ago
spikengineer 10y ago
If you don't use Apple Webkit view apple doesn't even allow you put your browser on the appstore. All other browser engines are banned. See section 2.5.6 of the Appstore guidelines "2.5.6 Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript." https://developer.apple.com/app-store/review/guidelines/ https://developer.apple.com/app-store/review/guidelines/
therealmarv 10y ago
Opera Mini bypasses this restriction with doing Server Rendering. I wonder why Apple is ok with them (because it'a a big security risk to server render HTTPS IMHO). And regarding your quesiton: I'm sure you cannot replace their webkit usage with one switch to Blink... I'm sure the iOS internal webview is deeply integrated/
- abrowne 10y ago
  Opera Mini, the app, is not rendering HTML as you say. They don't block VNC or RDP apps even though you can run a remote browser through them.
madeofpalk 10y ago
> locally compiled You can't "locally compile" code on iOS. That's against App Store guidelines.
- hawski 10y ago
  I am sure that he meant "locally" as on one's one computer without AppStore.
rweichler 10y ago
No. You can't map executable pages in the sandbox. JITs (such as LuaJIT) only work while the debugger is attached (i.e., you open the app by clicking "run" in Xcode).

bad_user 10y ago

Before iOS 9 (or something) that JIT engine wasn't even exposed in the web view available for apps, so no matter what you did, you couldn't match the performance of Safari. On iOS browsers like Chrome and Firefox are basically unable to compete in terms of performance, web standards or features like browser plugins. So people that use them do so just to get sync. Of course Safari Mobile is decent nowadays, but that's not the issue.

oatmealsnap 10y ago
Yea, it was always an outdated version of WebKit.
- JonathonW 10y ago
  Not outdated (it's always been the same WebKit version as used by Safari), but security restrictions on iOS (specifically, third-party iOS apps can't JIT-- the OS won't let apps without a specific entitlement execute from a writable section of memory) prevented in-app web views from using the same Javascript engine as Safari. iOS 9 eliminated that performance penalty-- it introduced a new kind of web view backed by an out-of-process renderer and JS engine, which, since it's Apple-blessed, doesn't have the JIT restriction. Third-party browsers updated to use the new framework can get the same performance as Safari.
  - gcp 10y ago
    Third-party browsers updated to use the new framework can get the same performance as Safari. But that framework is missing various things, such as content blocking. (That goes a long way to explain why there's both "Focus" and "Firefox" on iOS)
    - hendersoon 10y ago
      Exactly right. Lack of content blocking is why I don't use Chrome on iOS. I strongly prefer its UI and sync, but can't go back to seeing ads.
    - djrogers 10y ago
      > But that framework is missing various things, such as content blocking Not really - SFSafariViewController uses content blockers, autofill, etc. There's also WKWebView for those that want to implement their own content blockers and autofill engines. Curious why you'd want safari's content blockers to run inside chrome or firefox though? That's not how browser plugins work anywhere else, and it seems like if content blockers were forced in to 3rd party browsers there'd be a lot more angst over that decision. [1] https://developer.apple.com/library/ios/documentation/SafariServices/Reference/SFSafariViewController_Ref/ https://developer.apple.com/library/ios/documentation/Safari...
      - bad_user 10y ago
        Extensions like 1Password work in Firefox and Chrome but not content blockers. I know because I tested both. Mozilla also made a statement about it: https://motherboard.vice.com/read/heres-why-firefox-for-ios-cant-block-ads-like-it-can-on-the-desktop https://motherboard.vice.com/read/heres-why-firefox-for-ios-...
        st3fan 10y ago
        1Password only works in non-Safari browsers if those apps include a less optimal SDK that provides a generic password filling conduit. It is not something that WKWebView automagically does. See https://github.com/AgileBits/onepassword-app-extension https://github.com/AgileBits/onepassword-app-extension

oatmealsnap 10y ago

That might allow Chrome Extensions on iOS, but it seems like a lot of work to make that happen.

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.
- bzbarsky 10y ago

spikengineer 10y ago

If you don't use Apple Webkit view apple doesn't even allow you put your browser on the appstore. All other browser engines are banned. See section 2.5.6 of the Appstore guidelines "2.5.6 Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript." https://developer.apple.com/app-store/review/guidelines/ https://developer.apple.com/app-store/review/guidelines/

therealmarv 10y ago

Opera Mini bypasses this restriction with doing Server Rendering. I wonder why Apple is ok with them (because it'a a big security risk to server render HTTPS IMHO). And regarding your quesiton: I'm sure you cannot replace their webkit usage with one switch to Blink... I'm sure the iOS internal webview is deeply integrated/

abrowne 10y ago
Opera Mini, the app, is not rendering HTML as you say. They don't block VNC or RDP apps even though you can run a remote browser through them.

madeofpalk 10y ago

> locally compiled You can't "locally compile" code on iOS. That's against App Store guidelines.

hawski 10y ago
I am sure that he meant "locally" as on one's one computer without AppStore.

rweichler 10y ago

No. You can't map executable pages in the sandbox. JITs (such as LuaJIT) only work while the debugger is attached (i.e., you open the app by clicking "run" in Xcode).