Future support of WebView (macOS)

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.