4 ms·

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 performanc

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
      - gcp 10y ago
        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 Because there's currently no way for those browsers to get any content blocking without switching to the slower WebView. I'm fairly confident that both the Google Chrome team and Mozilla's Firefox for iOS team are better informed here than you are.
        st3fan 10y ago
        Not sure why this is downvoted because gcp is correct. Apple has decided that Content Blocking is a Safari only feature. Apple has made the decision to not expose the private APIs in WKWebView that would allow browsers like Chrome and Firefox to use the same speedy content blocking. The old WebView, UIWebView, also does not support content blocking. But since it runs completely in the same process as your app, you can replace the HTTP handling with your own and patch content blocking on top of that. That is what Firefox Focus and Brave do for example. It works, but it is far from ideal. Also, it is likely an API on the way to be deprecated.

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
    - gcp 10y ago
      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 Because there's currently no way for those browsers to get any content blocking without switching to the slower WebView. I'm fairly confident that both the Google Chrome team and Mozilla's Firefox for iOS team are better informed here than you are.
      - st3fan 10y ago
        Not sure why this is downvoted because gcp is correct. Apple has decided that Content Blocking is a Safari only feature. Apple has made the decision to not expose the private APIs in WKWebView that would allow browsers like Chrome and Firefox to use the same speedy content blocking. The old WebView, UIWebView, also does not support content blocking. But since it runs completely in the same process as your app, you can replace the HTTP handling with your own and patch content blocking on top of that. That is what Firefox Focus and Brave do for example. It works, but it is far from ideal. Also, it is likely an API on the way to be deprecated.