WebView and UIWebView Deprecated in Favor of WKWebView
I hope most of you have heard the news by now, but
UIWebViewhas been formally deprecrated.That means it is going away altogether in a future release.
Please start adopting
WKWebViewnow, and please ping me directly with any issues that arise.(Same goes for
WebViewon Mac)
The separate process architecture is nice, but this is going to be a rough transition. It looks like WKWebView is still missing tons of features from WebView (Web archives, DOM, customized loading and display, probably more that I haven’t discovered yet). The limitations are so severe that I bet a lot of apps haven’t even looked much into switching. Other features will be possible to port, but the API is very different, and in many cases you’ll need to switch from Swift/Objective-C to JavaScript. I was expecting to see massive improvements to WKWebView before WebView was deprecated, but that doesn’t seem to be happening.
See also: What’s New in Safari and WebKit.
Previously: WKWebView Workarounds, WKWebView, Sandboxing, and Searching, WKWebView.
Update (2018-06-20): The WWDC session has no useful information about switching to WKWebView, and the presenter implies that it’s easy.
As @mjtsai the inability to create web archives is a problem for me (and adding iOS support would be great), while printing / saving PDFs doesn’t work at all on Mac
On the subject, is there a way to invoke copy from a
WKWebViewwhile preserving rich text? I tried a while back and it doesn’t seem to work using the usualUIRespondermethods.
My main income is Stack for Rapidweaver. The vast majority of the UI handled by manipulating the DOM directly.
That is not possible in a
WKWebView.If
WebViewis removed my business will die and strand thousand of customers.
the issue is that they’ve cut off most of the fast APIs.
this was, i’m sure, done to improve security and avoid content policy injection.
unfortunately it really limits the utility of the view.
it’s basically just a web page viewer now.
Update (2018-06-23): See also: Core Intuition.
Update (2018-06-24): David Dunham:
I tried using it but got random crashes and went back to UIWebView.
We who rely upon WebView DOM manipulation really have our work cut out for us. We have to at least file the bugs with Apple and hope for accommodations where we need them.
Update (2018-08-01): Howard Oakley:
When WebViews are lost from macOS, a great many older apps will still expect to find them, and you should expect their behaviour to be untoward at least. I suspect that will kill far more apps than any future requirement for them to be 64-bit. And there’s no easy way to discover which apps are dependent on WebView.
Update (2018-08-10): Shazron Abdullah:
There are many limitations of WKWebview, especially if you were using UIWebView previously. The limitations are:
- Cookies don’t persist. This is a WebKit bug, but someone has created a plugin for a workaround. See CB-12074
- Can’t delete cookies. This is/was a WebKit bug (2015), we need to test for the iOS 11/12. See CB-11297
- Can’t execute JavaScript code in the background. There are several issues related to this. See CB-12815
- XmlHttpRequests don’t work, because of Cross-Origin Resource Sharing issue (CORS). There is a workaround plugin created by Oracle (UPL licensed, which is Apache-2.0 compatible). See CB-10143
- Migration of localStorage from UIWebView. There is a migration plugin available. See CB-11974
- iframes will not be supported any longer (they are now CORS restricted in WKWebView), and may be partially or completely broken. This may lead to incompatibilities with the same code in other Cordova platforms.
- Known issues with WKWebView on iOS pre-11 which will be deprecated and dropped in a future Cordova release
There are several bugs that need to be resolved as well. The full list here: https://s.apache.org/QfsF
Update (2018-11-26): See also: Core Intuition.
Update (2019-06-14): Brady Eidson:
It’s been a year since we formally deprecated UIWebView and WebView.
They’re still in iOS 13 and macOS Catalina but are still going away in future releases.
We’ve gathered tons of great feedback in the last year, but want even more.
Update (2019-08-15): Isaac Halvorson:
I’ve spent the last two weeks migrating a simple WebView to WKWebView in our macOS app due to an issue in Catalina. Now that I’ve finished, it works fine in Catalina, but is broken in pre-Catalina macOS versions. So I guess I’ll just inject one or the other depending on what OS?
This has been a ridiculous process, especially because of the huge lack of APIs WKWebView has compared to the old WebView. WebView makes things SO much easier. I had to write a ton of custom code just to make WKWebView do the same things WebView does out of the box.
Update (2019-11-06): Ken Case:
OmniWeb is in an awkward place right now, rebuilt on top of WebKit 2 only to discover it doesn’t support some essential features a daily-use browser needs—like password autofill.
14 Comments RSS · Twitter
I was expecting to see massive improvements to [QuickTime X] before [QuickTime 7] was deprecated...
I was expecting to see massive improvements to [Photos] before [iPhoto] was deprecated...
I was expecting to see massive improvements to [Apple Maps] before [Google Maps] was deprecated...
I was expecting to see massive improvements to [the Safari App Extensions API] before [the Safari Extensions API] was deprecated...
I was expecting to see massive improvements to [USB-C] before [everything else] was deprecated...
...but that doesn’t seem to be happening.
Soon:
I was expecting to see massive improvements to [Swift] before [Objective-C] was deprecated...
I was expecting to see massive improvements to [UIKit/Marzipan] before [AppKit] was deprecated...
I was expecting to see massive improvements to [iOS] before [macOS] was deprecated...
@vintner I actually do think most, if not all, of those examples have seen steady improvements that add up. And it’s not as if there was an Aperture API that lots of apps relied on. In fact, the API for Photos is better than what we had before.
@Michael Definitely not when it comes to the Safari Extensions.
For video APIs, I'm a bit dubious considering all the current incoherencies in movie playback on High Sierra when it comes to the new video formats.
@someone I’m not saying there’s parity with the Safari Extensions, but they do keep expanding what you can do with the new style extensions.
One piece of good news from the Safari session is that WebKit will be getting support for Service Workers. Given that Windows and Chrome already have support, hopefully that means fewer Electron-based desktop webapps in the future.
@vintner That comment is extremely aesthetically pleasing and semantically horrifying.
I was expecting to see massive improvements to [UIKit/Marzipan] before [AppKit] was deprecated...
I'll be gobsmacked if the official Marzipan release next year has any more Mac idioms/affordances than this year's four Marzipan apps exhibited in the first beta.
I'm glad I didn't know about XmlHttpRequests being broken. That might have dissuaded me from using them in my app where they work fine.
[…] there are a lot of limitations related to the use of WKWebView, well documented in a Michal Tsai article; we are going to mention the most important for […]
UIWebView was working perfectly in offline mode, but can't make it work in WKWebView. Any suggestion?
Deprecating objective-c is a death trap for any Adobe, Autodesk, MICROSOFT, and other large cross platform product.
Why don’t you people get that?
@Devboy Did you mean to post that comment on one of the SwiftUI posts? I don’t see how it applies here.
> UIWebViews no longer load as of iOS 13 beta 4.
They do load, I am using them.
WKWebView though has a startup cost that is much larger than UIWebView which is why I can't use it. I want to say show a Japanese document and if someone wants an english version, pull out a view with english loaded into it. This kind of on-demand use is fine with UIWebVIew but doesn't work with WKWebView for a couple of reasons:
1. it takes ages to get from alloc to functioning view compared to UIWebView ... it irritates the hell out of me that Apple came out with WKWebView with its typical "let's show the good parts and hide the bad parts" presentations and all the bloggers in the world just echoed it. So all you see is this marketing PR all over the place when trying to look at this issue. But the startup cost is way, way higher than UIWebView probably because of the cross process communication. It's significant and noticable to the user as a sluggish launch. UIWebView however was fine going way back on 5 year old hardware. I am testing this now on an iPhone XR and an iPad Pro and they cannot do what an iPhone 6s could do with UIWebView in terms of launch time.
Once loaded a WKWebView may be a better javascript processor, maybe loads URLs faster, but all of these cases are for people who are trying to develop a web browser. They make one monolithic view and start it up and leave it running. IF you have HTML that you want to display from other sources, inside your app, or dynamically parsed, you need an HTML viewer that is lightweight and fast. And WKWebView is not that.
2. That it is heavily more asynch reliant means that for local loading it is a lot slower even after started up than UIWebView. It may be faster for remote URL loading because the lag time going to and from a web server, plus its faster javascript engine and so many pages being javascript dependent cover this over. But UIWebView is indeed a faster viewer if you want to just do something like hand it an HTML string that doesn't contain Javascript or a ton of images or anything too complicated. The round trip time means that the UI will always be ready to receive a WKWebView before the WKWebView has rendered itself if you're talking about a quarter of a second animation times. This gives you a lot of white flashing and problems. A typical use case might be to put it as a leaf following a table view in a navigation controller.
Should you do that, you have two ugly choices: give a completion block and wait, in which case there is noticable lag before it can get itself done and on the screen, or you can just give it the HTML you want it to use and load it anyway in which case you get white flashes as the thing loads partway through the animation.
It's just not there to solve the same problems that UIWebView can solve. UIWebView can operate as this HTML snippet display, fast, light, easy, and doesn't require asynch calls.
Furthermore if you try to do something like an on-demand rendering of an HTML snippet that the user then dismisses, your app gets bombarded with OS level errors about the XPC and networking not found as the WKWebView endpoint gets removed.
This is just a terrible idea to try to get rid of UIWebView and replace it with WKWebView. For me, I'm blocking the deprecation errors for now. The slow startup you can solve by creating a WKWebView and have it sitting around idle for when you need to use it and not dealloc it, but this directly defeats one of the claimed advantages of this object which was lower memory overhead. That I can create, and dealloc a UIWebView with no hassle and return to 0 memory use is a lot better memory overhad than a WKWebView which has to exist through my app's life time case it might be used. Also is more subject to memory leaks and now needs to be manually wound down by feeding it "about:blank" and then hoping it is smart about reducing resources.
Apple though will do what Apple always does: force it down our throats and if you don't like it too bad.
