Hi All, After the discussions here and via social media (yay!), we have some feedback from people who have been working (fighting) with UIWebView on iOS. The overwhelming majority suggest moving to WKWebView. If we start with WKWebView, we need to keep an eye on the upstream source [1], watching for (and contributing?) patches that give us the support we need.
So for now, let's start development using WKWebView. Nothing is set in stone, but the future of embedded web views on iOS seems to be WKWebView. Thanks, Finkle [1] http://blog.persistent.info/2014/07/the-modern-webkit-api-is-open-source.html ----- Original Message ----- > Background: we have two choices for embedding a web view in an iOS > application: UIWebView, which has been there since the early days, and now > with iOS8, the new WKWebView. The UIWebView is what for example Chrome and > pretty much every other third-party app uses while WKWebView is what Safari > (and newer third party apps) uses. > The UIWebView is very minimal but it gets the job done. Basically you can ask > it to load content, handle navigation and execute JavaScript when a page has > loaded. But, no JIT. So about 3x slower than WKWebView. > The WKWebView is new with iOS8 and exposes a much richer API. It has for > example wonderful gesture support so you can swipe left just like in Mobile > Safari. It also supports user scripts much better, which would allow us to > introduce HTML5 APIs that WebKit does not know about. And it runs Nitro at > full speed. > It seems obvious to use the new WKWebView but there is a big limitation: it > is impossible to intercept the URL Loading System. I found this out when I > was trying to add support for a custom header (DNT) in a little experiment. > https://github.com/st3fan/WebKitExperiments/blob/master/DoNotTrack/BasicBrowser/ViewController.swift#L6 > How this works is as follows: by providing a custom NSURLProtocol class it is > relatively trivial to intercept URL loading. In my example I simply build on > top of the built-in NSURLConnection and the only custom thing I do there is > to add a DNT header for outgoing requests. This same mechanism can also be > used to inspect and modify requests for things like Mixed Content detection > and would probably be part of Tracking Protection. > Now the sad news. Unfortunately this only works on UIWebView. I see that my > `CustomURLProtocol.canInitWithRequest()` is being called, but other than > that nothing happens. I assume this is because the WKWebView executes > network and content in a remote process. Which is good for security and > performance, but closes the door to customizations like this. > So, it seems we have to make a choice between slower UIWebView or a less > optimal WKWebView. > Note that there is not a good product definition just yet, but because so > many of our better features depend on access to networking, I can only > assume this will be a problem in the long run. > I’ve been staring at this for a while now and I don’t really see a good > workaround. I’d love to hear some suggestions or questions. > S. > _______________________________________________ > mobile-firefox-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/mobile-firefox-dev
_______________________________________________ mobile-firefox-dev mailing list [email protected] https://mail.mozilla.org/listinfo/mobile-firefox-dev
