Future support of WebView (macOS)

Hi all,


in the news post "Updating Apps that Use Web Views", Apple states that Apps have to switch over from using "UIWebView API" to using "WKWebView" in order to be accepted/updated in the AppStore after 2020.

https://developer.apple.com/news/?id=12232019b


Does anyone here have any information on how this relates to macOS Apps using the (also deprecated) WebView (not UIWebView) class of WebKit? The macOS framework is not mentioned at all in the post.


I contacted the (german) Apple Developer support, but after a few emails I am still not sure if they understood my question and if they are actually aware of said news post (to which I included a link in my mails)... The last response I got was:

"We currently have no information that Apps using the UIWebKit will be excluded from the App store."


Notice they write "UIWebKit"... I am not sure if they are not aware of the existence of the macOS class "WebView" or if it was just an innocent typo. In a way that response could even be seen as a direct contradiction to the original news post...


My App still uses the WebKit's WebView, as it relies on its DOM classes and the more powerful API to manipulate the DOM via Objective-C rather than only having access through the "execute java script" call. It would be great if someone here could clarify this issue or has some more information.


Thank you!

Replies

I don't understand your question either. Clearly the legacy WebKit API is dead and all Apple developers should be transitioning from it. Is there something that makes you think that this is not inevitable and immediate?


Mac developers have a little bit more breathing room due to Apple's general neglect of the Mac platform in general. WkWebView can't print on the Mac and you need to use a legacy web view for that. But the rumour is that a fix is "locked down", whatever that means.


But here is the problem. In June, I'll have to figure out how to get WkWebView to print. That might take a few days and could involve some bug reports that Apple isn't likely to get fixed until late. You are going to have to rewrite your whole architecture. Better get started on that.

Well, I guess my question is:

Will macOS Apps using the WebView (not UIWebView) be allowed in the AppStore after December 2020?



My understanding of "depricated" is that the API should no longer be used in newly developed software, not that it should be replaced immediately. It does not imply that the API would no longer be available. The news-post on the other hand says that the UIWebView will no longer be available and so I wondered if that would also be the case for the WebKit or not.

>My understanding of "depricated" is that the API should


No. I think you're conflating.


WebKit is an API. WKWebView and UIWebView are classes. Both WKWebView and UIWebView are part of WebKit.


By default, if you're using the -class- WKWebView, you're using the -API- WebKit.


WebKit (API) - not deprecated

WKWebView (class)- not deprecated

UIWebView (class) - deprecated

> Will macOS Apps using the WebKit be allowed in the AppStore after December 2020?

Nobody can answer that.


> My understanding of "depricated" is that the API should no longer be used in newly developed software, not that it should be replaced immediately.

Your understanding is incorrect. When an API is deprecated, it should be replaced or discontinued. This means that Apple plans to remove it. More importantly, it means that Apple immediately ceases to support it. It can break unexpectedly due to some other minor change.


The news-post on the other hand says that the UIWebView will no longer be available and so I wondered if that would also be the case for the WebKit or not.

It should be obvious at this point that WebKit is dead. As I said before, the reason it is still allowed on the Mac APIs is due to Apple's neglect of the platform, not any desire to maintain the API. Furthermore, it should be obvious that the entire Mac API will soon follow suit. It isn't formally deprecated, but that is only due to the inevitable media reports that would result. The Developer support personnel you contacted don't seem to know anything about the Mac APIs. That wasn't any kind of contradictory information or official statement from Apple. They simply don't know anything about Mac development.


These forums are full of developers who ignore these deprecation notices, the direct e-mails, and what should be considered obvious roadmap intentions by Apple. Then, when something is formally removed, or something unexpectedly breaks, they come here and complain. For the server side issues involving App Stores or Notarization, sometimes Apple caves and delays new policies. These developers then sit on their hands and do nothing other than ask questions about what it means when these delays expire and what, precisely, is going to happen in the future. To be honest, it is really frustrating.


You know what is going to happen. When did you code that DOM-management layer? Was it after 2014? Because that was when Apple killed it. You need to transition your code to Javascript. Do this now. You have 5 months before your code breaks. You had five years, but now you have five months.

Regardless of the App Store rules (and, AFAIK, we’ve not announced anything specific on the Mac side of things), the situation with

WebView
is pretty clear: It has been formally deprecated and you should work to find a way to transition to
WKWebView
. Which brings us to this:

it relies on its DOM classes and the more powerful API to manipulate the DOM via Objective-C

Some folks are able to make good progress on this front by moving the boundary between their native and web code to the web site of things. I recommend that you explore that option in depth. If you hit things where that’s simply not possible, you should definitely file an enhancement request against

WKWebView
. And please post your bug number, just for the record.

However, make sure to keep in mind that

WKWebView
has a very different architecture than
WebView
, and certain things are simply not possible in that architecture. Specifically,
WKWebView
runs the bulk of the code in a separate process, and that’s not a bug but a very specific feature based on security requirements (if you’re curious about the background to this, watch WWDC 2018 Session 207 Strategies for Securing Web Content).

I was recently talking with an iOS developer who was getting [1] the

JSContext
from a
UIWebView
and then calling JavaScriptCore APIs on that. This is simply not feasible in the
WKWebView
architecture, because that
JSContext
lives in a separate process. You could imagine us adding an IPC shim to JavaScriptCore, so every JavaScriptCore call bounced over to the process actually running the context, but that would be much slower, so much slower that it’d probably be useless to you. And that’s why my advice above is about moving the boundary between your native and web code, to put do more work on the web site and hence reduce the IPC burden.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

[1] Using a private API )-: This is a classic example of how using private APIs can paint you into a corner.

Thank you so much for this reply! That's the information I was hoping for and helps me plan the future development and transition much better 🙂

My main concern with moving everything over to JavaScript was that the (sometimes complex) DOM manipulations the app does require full undo/redo support and that seemed somewhat unstable if I had to pipe it through JS. Will give it another try though and, once I have more concrete experience, file enhancement requests as you recommended.

the app does require full undo/redo support and that seemed somewhat unstable if I had to pipe it through JS.

Yeah, that does sound tricky.

Good luck!

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I have the same situation, where I still need to use the 'WebView' on Mac. I would like to transition to the new `WKWebView`, but it does not currently support printing. IE: If you put this view into another view, and try to 'print' the view into a PDF file, it's blank. The old WebView supports this function correctly, it will print into a PDF just fine.


Is there a way to make WKWebView able to print into a PDF file without issue, just like any other view I use can do? Like I said, I would love to be able to move to the new web-view. I have all the code ready to go, it's just this missing ability that prevents me from being able to use it.

Is there a way to make WKWebView able to print into a PDF file without issue, just like any other view I use can do?


No.


Supposedly this was fixed in WebKit over 4 years ago: https://bugs.webkit.org/show_bug.cgi?id=151276

But that doesn't help since the Apple apparently hasn't shipped an update to this API in 6 years.

FWIW Mail.app still seems to use the legacy WebView, so maybe we'll be able to enjoy the DOM API for a little longer.