{"id":46193,"date":"2020-02-10T09:06:21","date_gmt":"2020-02-10T17:06:21","guid":{"rendered":"http:\/\/devblogs.microsoft.com\/xamarin\/?p=46193"},"modified":"2020-03-04T02:23:56","modified_gmt":"2020-03-04T10:23:56","slug":"uiwebview-deprecation-xamarin-forms","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/xamarin\/uiwebview-deprecation-xamarin-forms\/","title":{"rendered":"UIWebView Deprecation and Xamarin.Forms"},"content":{"rendered":"

A little while ago, Apple started sending out warning messages about the <\/span>UIWebView<\/span><\/code> deprecation. This has\u00a0<\/span>not gone unnoticed<\/span><\/a>\u00a0by our\u00a0<\/span>Xamarin.Forms<\/span>\u00a0users, who directly created an issue for it. Today we have some great news to\u00a0share:\u00a0we have a solution for you! This post will give you a bit of background about our considerations and of course, how to avoid rejection to the Apple App Store.<\/span>\u00a0<\/span><\/p>\n

The History of\u00a0UIWebView<\/span>\u00a0<\/span><\/h2>\n

UIWebView<\/span><\/a> has already been around since iOS 2.0 but <\/span>has<\/span>\u00a0been deprecated since iOS 8.0. Its successor, <\/span>WKWebView<\/span><\/a>,\u00a0<\/span>of course,<\/span>\u00a0does the same thing\u00a0<\/span>functionally but<\/span>\u00a0has some advantages over the old\u00a0<\/span>UIWebView<\/span><\/code>.<\/span>\u00a0<\/span><\/p>\n

As soon as the\u00a0<\/span>UIWebView<\/span><\/code> deprecation became known, the\u00a0<\/span>Xamarin.Forms<\/span>\u00a0team\u00a0<\/span>worked to make a replacement\u00a0<\/span>WKWebViewRenderer<\/span><\/code>. While it has been available in Forms for a long time now, the default was still the\u00a0<\/span>UIWebViewRenderer<\/span><\/code>.<\/span>\u00a0<\/span><\/p>\n

Shortly after the introduction of iOS 13, Apple decided to send out warning messages about the <\/span>UIWebView <\/span><\/code>deprecation. The warning would read:\u00a0<\/span>\u00a0<\/span><\/p>\n

ITMS-90809: Deprecated API Usage – Apple will stop accepting submissions of apps that use\u00a0UIWebView\u00a0APIs. See\u00a0https:\/\/developer.apple.com\/documentation\/uikit\/uiwebview<\/a>\u00a0for more information.<\/p>\n

After you\u2019ve corrected the issues, you can use\u00a0Xcode\u00a0or Application Loader to upload a new binary to App Store Connect.<\/p><\/blockquote>\n

This warning was still a warning and would not prevent you from publishing your app at the time. A few months after this,\u00a0<\/span>Apple announced<\/span><\/a>\u00a0that as of April 2020 they reject new apps still referencing\u00a0<\/span>UIWebView<\/span><\/code>. For updates to apps the deadline is December 2020. Of course, we want to be ready well before then, and we are.\u00a0<\/span>\u00a0<\/span><\/p>\n

Maintain Backwards Compatibility for\u00a0Xamarin.Forms<\/span>\u00a0<\/span><\/h2>\n

With\u00a0<\/span>Xamarin.Forms<\/span>\u00a0we strive to maintain backwards compatible the best we can. This issue challenged that quite a bit. As you might know, or maybe have experienced, the linker for the iOS platform can be\u00a0pretty aggressive. What it does is strip out any APIs that are not referenced from your code in order to make the resulting binary of your app smaller.<\/span>\u00a0<\/span><\/p>\n

Because of this, we thought the solution would be to simply switch the default renderer to the\u00a0<\/span>WKWebViewRenderer<\/span><\/code>. By doing that, there would be no reference to the\u00a0<\/span>UIWebView<\/span><\/code>\u00a0anymore and it would be taken out by the linker.<\/span>\u00a0<\/span><\/p>\n

While working on this, we discovered that the linker does\u00a0<\/span>a fantastic<\/span>\u00a0job, but the\u00a0<\/span>Xamarin.Forms<\/span>\u00a0binary was excluded from linking by default. That would mean\u00a0<\/span>as long as<\/span>\u00a0the\u00a0<\/span>UIWebViewRenderer<\/span><\/code>\u00a0file would exist in our codebase, ultimately apps would be rejected.<\/span>\u00a0<\/span><\/p>\n

This was a problem, because if we want to keep up our backwards compatibility game, we couldn\u2019t just delete the\u00a0<\/span>UIWebViewRenderer<\/span><\/code>. This would potentially break custom renderers or other code that referenced this class implemented by\u00a0<\/span>Xamarin.Forms<\/span>\u00a0users. Therefore, we went looking for another solution.<\/span>\u00a0<\/span><\/p>\n

Xamarin.iOS<\/span>\u00a0Team to the Rescue<\/span>\u00a0<\/span><\/h3>\n

During our quest for a solution we had multiple options. For example: making stubs or rewriting the\u00a0<\/span>UIWebViewRenderer<\/span><\/code>\u00a0to use\u00a0<\/span>WKWebView<\/span><\/code>\u00a0underneath. The most obvious\u00a0<\/span>option,<\/span>\u00a0however, would be to find out if we could make the linker work for\u00a0<\/span>Xamarin.Forms<\/span>\u00a0as well.<\/span>\u00a0<\/span><\/p>\n

We have worked closely with the\u00a0<\/span>Xamarin.iOS<\/span>\u00a0team to make that happen. On top of that, we are proud to say that we have a solution that does exactly that.<\/span>\u00a0<\/span><\/p>\n

Because\u00a0<\/span>Xamarin.Forms<\/span>\u00a0has been excluded from the linker since forever, we first want to make sure that everything continues to work as expected. Because of that, this new linker behavior is behind a feature flag for now.<\/span>\u00a0<\/span><\/p>\n

Prevent App Store Rejection, Today!<\/span>\u00a0<\/span><\/h2>\n

The solution only involves three steps:<\/span>\u00a0<\/span><\/p>\n