[JonathonW]

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]

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)

[djrogers]

> 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/Safari...

[st3fan]

> Curious why you'd want safari's content blockers to run inside chrome or firefox though?

Because WKWebView has such a limited API that it currently is impossible to implement content blocking.

WKWebView is both a blessing and a curse for browsers like Chrome and Firefox.

A blessing because tt works really well inside that square area where content is rendered. It is as fast as Safari, as responsive to touch gestures, supports web APIs pretty well.

A curse because the API that it exposes is completely lacking. No way to intercept network requests, no way to interact with the DOM, no way to interact with JavaScript, no way to customize it fully, no way to do proper session store/restore, no way to interact with its internal caches, no way to set the cookie policy, no way to customize the context menus that it exposes, no way to handle errors better, no way to set headers on requests, no way to use content filters ..

I can go on for a while. You can look at the Chrome and Firefox source code to understand the crazy workaround both browsers had to do to get some pretty basic functionality.

Search for WKWebView on https://bugz.webkit.org to see what people have been asking for, for the past three years.

[gcp]

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]

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.

[st3fan]

> Not really - SFSafariViewController uses content blockers, autofill, etc.

SFSafariViewController is useles for apps like Chrome and Firefox. It is an embedded Safari controller. Not an embedded generic webview controller.

SFSafariViewController has zero API. All it can do is display a webpage. Applications that use it have zero ability to even modify the UI.

That is intentional. It is supposed to be a Safari view. And for security reasons that is probabl good, otherwise it would be a gateway to your browsing data.

[bad_user]

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-...

[st3fan]

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

[hendersoon]

SFSafariViewController 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

[hendersoon]

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.