FWIW, Google Chrome will switch to WKWebView. I read about it in the news, but can't find the source anymore. They've been waiting for it.
I'd ask Apple to implement a way to do what you need. Stefan Arentz wrote, On 08.12.2014 21:18: > 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
