Make WkWebViewRenderer default for iOS WebView

[jfversluis]

Description of Change

Deprecates the WebViewRenderer for iOS and uses the WkWebViewRenderer instead.

No (extra) automated tests were added at this stage, the ones in place should succeeded with this replacement.

To reinstate the current behavior just add the line below to the AssemblyInfo.cs file of you iOS project. This will register the WebViewRenderer again over the WkWebViewRenderer.

[assembly: ExportRenderer(typeof(Xamarin.Forms.WebView), typeof(Xamarin.Forms.Platform.iOS.WebViewRenderer))]

Issues Resolved

• Partially fixes ITMS-90809: Deprecated API Usage - Apple will stop accepting submissions of apps that use UIWebView APIs #7323

API Changes

None

Platforms Affected

• iOS

Behavioral/Visual Changes

None. Everything should function as before. Users should receive build warnings when they reference the WebViewRenderer directly. E.g. when there is a custom renderer in place.

Before/After Screenshots

Not applicable

Testing Procedure

PR Checklist

• Has automated tests
• Rebased on top of the target branch at time of PR
• Changes adhere to coding standard

[adrianknight89]

I thought the OP said he was already using WkWebViewRenderer when he got the warning. If that's the case, shouldn't the old renderer be completely removed from the source code instead of being marked obsolete?

[jfversluis]

I think that is something we need to investigate. I also see some reports of people implementing a renderer with WkWebViewRenderer and the message does disappear.

Removing the old renderer altogether is not something that I would want to do. That will immediately break peoples code whenever they have any reference whatsoever to that class.

If there is no reference to it, it should be removed by the compiler and all should be good.

[PureWeen]

@jfversluis

If there is no reference to it, it should be removed by the compiler and all should be good.

I ran some tests with this and it is not removed.

If you run a default iOS app currently with full linker on even the WkWebViewRenderer sticks around if you aren't using it. The intent of the RenderWith attributes was to link anything out for elements you didn't use but I don't think that behavior is currently working correctly.

So I don't think this PR will really achieve anything currently

[adrianknight89]

So, what now? Fix the linker behavior or introduce a breaking change and remove the old renderer?

[PureWeen]

Fix the linker behavior or introduce a breaking change and remove the old renderer?

My current thought would be to figure out why those renderers aren't getting linked out (which I've been working on a bit). If RenderWith isn't resulting in Renderers being linked out then I don't think it and the whole Forwarders thing serves any purpose (right?)

In that case we could switch the default type (like in this PR) and then leave the WebViewRenderer in. If people need to revert back to WebViewRenderer they can add the Export for it but if people aren't using it then hopefully it gets linked out.

[StephaneDelcroix]

need doc on how to revert to original behavior. no need for a blog post, but a few lines in the PR description

[PureWeen]

@jfversluis can you rebase to master? I just merged 4.3.0 up so we should be able to get this through the UI tests

In theory for this change to get rid of the warning we also have to delete this out of the AssemblyInfo
https://github.com/xamarin/Xamarin.Forms/blob/master/Xamarin.Forms.Platform.iOS/Properties/AssemblyInfo.cs#L61

Though that currently does nothing (as we know and bug logged with iOS)

So we might want to include deleting that as part of this PR and working through whatever needs to be worked through with the linker to make sure our code still works.

[PureWeen]

@jfversluis never mind about removing

https://github.com/xamarin/Xamarin.Forms/blob/master/Xamarin.Forms.Platform.iOS/Properties/AssemblyInfo.cs#L61

The WebViewRenderer will never get linked out no matter how much it wants to.
So let's just merge this after it's rebased and the UITests pass

[jfversluis]

Short summary: there is no way to get the (UI)WebViewRenderer linked out through the mechanism we have in place. As a first step to swap out the WebViewRenderer and WkWebViewRenderer we would merge this PR.

People submitting apps to Apple will still receive the warning, but it's just that: a warning. Probably by the time iOS 14 starts knocking on the door Apple will start actually rejecting apps still referencing UIWebView.

Because we can't link out the (UI)WebViewRenderer, we need to delete it as a whole. This will be a breaking change for everyone still referencing it. In a follow up PR somewhere in the future we will need to do this or come up with something better. For now, this is the solution to at least warn our users that they should start removing references to this renderer.

[adrianknight89]

@PureWeen @jfversluis For those of us who want to remove the old renderer completely, you could fix #5815 so that we could use Azure DevOps for custom builds. Right now, I use cake to build locally, but I'd rather integrate with DevOps.

This page needs to be updated to remove VSTS:

https://github.com/xamarin/Xamarin.Forms/wiki/How-to-Build-Xamarin.Forms-NuGet

#3430 was fixed, but this was ignored.

[PureWeen]

@adrianknight89 working on that over here

#7458

Once I have it to a point where there's a path that the public can use I'll let you know and you can let me know how it works out for you

[adrianknight89]

Thanks Shane!

[jfversluis]

Fixed the tests for iOS. It seems UITest also has some issues with UIWebView -> WKWebView. I will report that to them.

Namely:

• The WebView shorthand method defaults to UIWebView
• The Css method does not seem to detect all the elements anymore. There for I had to change the assert to the a element instead of the h1 which is entirely not detected anymore
• Tap on a CSS selected element does not seem to work. The coordinates are detected but a tap is never executed

[jfversluis]

Failed tests are not related (CarouselView one)