8 Replies
      Latest reply on Jan 15, 2020 1:36 PM by eskimo
      faax Level 1 Level 1 (0 points)

        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!

        • Re: Future support for WebKit/WebView (macOS)
          john daniel Level 4 Level 4 (550 points)

          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.

            • Re: Future support for WebKit/WebView (macOS)
              faax Level 1 Level 1 (0 points)

              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.

                • Re: Future support for WebKit/WebView (macOS)
                  KMT Level 9 Level 9 (15,425 points)

                       >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

                  • Re: Future support for WebKit/WebView (macOS)
                    john daniel Level 4 Level 4 (550 points)

                    > 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.

                • Re: Future support of WebView (macOS)
                  eskimo Apple Staff Apple Staff (12,725 points)

                  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.

                    • Re: Future support of WebView (macOS)
                      faax Level 1 Level 1 (0 points)

                      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.

                        • Re: Future support of WebView (macOS)
                          eskimo Apple Staff Apple Staff (12,725 points)

                          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"