5 ms·
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
by 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 agoThird-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 agoExactly 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 agoExtensions 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 ago1Password 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 agoCurious 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 agoNot 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.
- hendersoon 10y agoSFSafariViewController essentially IS safari. It isn't appropriate for a third-party browser. While it is technically possible to use content blockers in WKWebView, it can only be done via private APIs, and Apple capriciously bans apps from their appstore that use private APIs. Reference: https://bugs.webkit.org/show_bug.cgi?id=150479 https://bugs.webkit.org/show_bug.cgi?id=150479