I am getting this problem too, we're using: Xamarin.Forms 3.6.0.539721

Every version of Forms will get this because WebViewRenderer in iOS implements UIWebView, and the file stays even if you switch over the WkWebViewRenderer. I don't know if there is a way to Link that file out during the build.

@swansca79 - that's pretty much what I was afraid of. I'm hoping we can link it out as you say.

What is Apple's deadline on this requirement? I couldn't find any...

I'm guessing this affects all apps regardless of whether they are new submissions or updates. If that's the case, then what's the point of linking out the old renderer? It should be removed from the source code. Also, we need to find out if this is an iOS 13 requirement or not...

Same problem here. I'm using Xamarin.Forms 4.2.0.709249

I added the following line in the AssemblyInfo.cs of the iOS project but that doesn't change anything :

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

I would like to know Apple's deadline for app submission too.

Same problem here.
Anyone knows the Apple's deadline for this req? Or if Xamarin is working on this update

UIWebView is still in the iOS13 betas, so probably have until iOS14.

If you look at the Xamarin.Forms.iOS renderers folder you would see that they added WKWebViewRender 2 months ago. I Asume that you could create your own WebView that inherit from that renderer (if you don't have the lastet version of XF on your project you can copy/paste the code) to fix this issue with your WebViews

WkWebViewRenderer.cs

Guys, I find something weird, I changed app bundle identifier and submitted it to app store again, and I did not receive the warning e-mail from apple.
And my situation: three day ago, I did not receive any warning e-mail from apple after submitted ipa to testflight, and then I receive the e-mail after I make some changes which is no relationship with webview, then I try to find why with following ways:
1.Try to replace UIWebViewRenderer with WKWebViewRenderer;
2.Remove WebView;
3.Remove the third-party nuget lib(I added recently);
But they are useless about the warning(I still receive the warning e-mail).
I don't know how the ipa was checked by apple, is there any possibility that they make some mistakes?

I noticed that this situation appears with flutter and react-native recently.(The developers meet the problems too.)

@Carl-Wen this happens with Ionic apps too

I got the same message from Apple Store Connect today. Weird thing is my application does not have any web view in it. I have also tried looking at the Xamarin plugins to see if any of them use, but it seemed none of them are using UIWebView (not 100% sure though because there are also dependencies of dependencies).
Does anybody know how to identify UIWebView usage in the application?

The same thing happens to me. First time trying to submit an app

I got the same warning from iTunesConnect today

I also get same error few days ago, is there any workaround?

Please check my answer up here, I have a project on Xamarin.Forms 3.6.x and it uses some webviews, so I've created a custom renderer for WebView only for iOS and changed the inherit from UIWebViewRenderer to WKWebViewRenderer. Yesterday I uploaded the application to the store and didn't receive any warning.

the same issue

@FabriBertani Could you share your custom render code please?

I've got the same issue, but my app DOES NOT use any Web Views. I'm assuming Apple is detecting the usage in the Xamarin.iOS library.

Do you have any solutions or workarounds for this one? Also happened when we uploaded our app. We also do not use WebViews and it seems @dhewitson is right that it is because of the UIWebView on the Xamarin library.

Assuming you don't have any package that uses UIWebView that you can't control, this should be enough. Then just use your custom rendrer instead regular XF WebView

namespace YourAppNameSpace
{
    public class CustomWebView : WebView
    {
    }
}

[assembly: ExportRenderer(typeof(CustomWebView), typeof(CustomWebViewRenderer))]
namespace YourAppNameSpace.iOS
{
    public class CustomWebViewRenderer : WkWebViewRenderer
    {
    }
}

Same issue, does any one have an update on this?

Hey everyone! Thanks for reporting and your research.

We are tracking this and a renderer for WkWebView is already in place for a while. I have moved forward on a PR making that renderer the default and deprecating the UIWebView one. With that, this error should disappear.

I expect some reviews and feedback on my PR from the rest of the team, but hopefully this should be resolved soon.

Hi @jfversluis would it be possible that the fix can be applied to older version of XamarinForms?
I'm using 3.4.0.1009999 and it would be so much effort to upgrade to newest version of Xamarin.Forms.

@ngoquoc we might backport this to earlier versions, but I'm sceptical that we will take it back all the way to 3.4, sorry. Why is it too much effort to upgrade? It might be worth investigating that area :)

@jfversluis thanks for lightning fast reply :D
I absolutely agree that it's worth upgrading to newer version, but the situation is it's really close to our planned release deadline. And we have many legacy dependencies (which only supports up to XF 3.x) as well as usages of newer version's breaking changes.

@ngoquoc No problem! I understand completely! For your next release I do think it's wise to look for upgrading though. There might be more APIs that will deprecate or deprecate soon. If there is anything we can do to make your upgrading experience better, please reach out!

Hopefully we can apply the fix of this issue on 3.4. Upgrading to 4.x is absolutely in our plan and we will reach out the team if we need helps (hopefully not :D). Really appreciate your support!

@ngoquoc In any case, as written above, while you can upload your ipa, and in iOS13 this class is still there.
So, this will work for some time

@KSemenenko did you mean "warned" app can be also published to the Apple store?
If that's the case, great, we can calm down and postpone switching to WKWebView for some more time :D
My only concern is whether Apple approves such application with warnings.
I found the published information about deprecation here, but no official deadline/Apple store review policy is specified: https://developer.apple.com/documentation/uikit/uiwebview

@ngoquoc Historically, yes they will still approve those apps for now. The warning is basically saying "hey, we'll approve your app for now, but in the future we are not going to so you should switch ASAP". As long as you publish before they decide to switch that to an error you are good.

Thanks. I will try submitting the app now and get back to you guys with the result perhaps in a few days after Apple reviews it :)

@ngoquoc yesterday I was able to upload ipa to AppStore.

Copied from
https://github.com/xamarin/Xamarin.Forms/pull/7367#issuecomment-527558598

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.

One reason that I've found is that our platform assemblies both have the
PreserveAttribute specified at the assembly level which looks to force the assembly to retain all the types

I tested by adding a dummy class to our platform project and with the PreserveAttribute the class stays around but without it the PreserveAttribute goes away.

The renderers still all stick around :-) but it's a baby step

I ran a quick test with the CheckboxRendererDesigner class (because it's not really used anywhere)

And if I remove both these lines of code
https://github.com/xamarin/Xamarin.Forms/blob/d56942c5bee0a7c56255febc8bbcc6bc33d5e1cb/Xamarin.Forms.Platform.Android/AppCompat/FormsAppCompatActivity.cs#L128

https://github.com/xamarin/Xamarin.Forms/blob/bcf1d857f70c2d521fdbf59bd73445c7e77fe1fc/Stubs/Xamarin.Forms.Platform.cs#L112

Then it gets linked out.

It seems like the intended purpose of RenderWith on these forwarder projects
https://github.com/xamarin/Xamarin.Forms/blob/bcf1d857f70c2d521fdbf59bd73445c7e77fe1fc/Stubs/Xamarin.Forms.Platform.cs#L112

Aren't providing the weak enough connection that was hoped for

It looks like this is happening because the Checkbox (forms element) itself isn't being linked out which then causes the RenderWith attribute to keep the Renderer around.

If I change the CheckboxRendererDesigner to attribute some non existent class
```C#
[RenderWith(typeof(CheckBoxRenderer))]
internal class _CheckBoxRenderer { }

[RenderWith(typeof(CheckBoxDesignerRenderer))]
internal class _CheckBoxRendererIsMyNameo { }

```

Then it gets linked out...

So need to figure out how to link out the CheckBox

Have others seen the warning go away by doing this?

https://github.com/xamarin/Xamarin.Forms/issues/7323#issuecomment-527294907

@PureWeen

Didn’t work for me, I have both the renderer and the entry in the assembly file and still get the warning.

Did you mean that just add WKWebViewRenderer is not enough for this warning e-mail?

@PureWeen

Didn’t work for me, I have both the renderer and the entry in the assembly file and still get the warning.

In that case maybe you have any other package that uses UIWebView, i just use that workaround and don't get any warning from App Store :)

Hi @ngoquoc any luck with the review process yet?

would just like to know if our app deadline will be met if submitting for review regardless of the 'warning'.

I guess we need to know when Apple will start deeming this grounds to reject an IPA file. I fear they will not publicly announce this.

Today I received a letter that my app I passed apple review
so for now it works :)

App review work as usual. My new app just published normally. Maybe just a warning for future release.

Usually warnings are just warnings and they give you a lot of time. In the case of Google they give you about 2 years. My assumption here is that the warning is to tell you that they are going to remove it from iOS 14 (my guess) and that they really want you to stop using it. Although if you flipped the switch or if it is on by default you wouldn't be using it anyways. So unless they flip the switch and make it an error, which i don't think they would because some people still need to support older devices.

OK, so here is what I did to verify what is going on.

Created a dummy app which I uploaded to Apple with the latest stable Xamarin.Forms package and the app showing just a WebView. Soon after I uploaded it, I got this warning. To verify that the warning goes out every time, and thus to verify we can assume that when the warning does not come we have fixed the issue, I have created another binary with no changes besides the version number. The warning message came again. So that confirms: whenever you stop receiving the warning, apparently the issue is fixed.

Then I went ahead and implement a custom renderer with the exact code that @FabriBertani provided here. The message still came. So this does not seem to be a solution.

I then took this branch and just deleted the WebRenderer and effectively removed all references to the UIWebView. This had the desired effect. Apple now no longer sent me the warning.

All this does seem to point to the fact that as long as we reference UIWebView in our code (read: as long as the UIWebViewRenderer is still in place) Apple will detect it and ultimately will stop accepting the app. To obtain maximum backwards compatibility we need to investigate why the linker does not remove the WebViewRenderer when it's not being used anymore. If we fix that, my PR makes sense and should fix this problem for once and for all.

Like James (and others) mentioned, it's just a warning for now, so even if you get the message, at this point there is nothing to worry about and it will work. But of course we need to be prepared for when Apple does decide to stop allowing the old UIWebView API.

So after checking with the iOS team it looks like anything that inherits from NSObject will never get linked out so the promise of RenderWith to link out renderers I'm pretty sure never worked on iOS

Given that we're going to just have to delete the renderer completely and break everyone

Or get crafty with a separate nuget and some type forwarding

I have also the same problem. Any update on this?

Hi @Mikilll94, we are actively working on this, however a full solution will not be available anytime soon. With a "full solution" I mean that the warning will stop coming from Apple whenever you submit a Xamarin.Forms app to the store.

To stop the warning message we need to remove the current WebViewRenderer from the source completely. Since that renderer is the default right now and has been in the source since forever, this is a major breaking change. With the PR associated to this issue we are switching the default renderer to WKWebViewRenderer which will effectively use the new WKWebView. End-users of Xamarin.Forms should not notice anything about this change. With this switch, we are also marking the original WebViewRenderer as deprecated to give the Xamarin.Forms users the possibility to make the necessary changes in their code. For example if they have custom renderers in place that rely on the WebViewRenderer.

However, because the WebViewRenderer is still linked in the source, this is still something Apple picks up while scanning your app. In a later version of Xamarin.Forms, which is at it's very earliest version 4.5 we will drop the WebViewRenderer entirely and with that the warning messages from Apple should stop.

Having that said, there are two things to take away:

1. The message from Apple is just a warning for the time being, there is nothing stopping you from submitting new versions and they should be accepted into the App Store just fine. This will probably continue to be so until iOS 14 which gives us (at least) a year.
2. Again, dropping the WebViewRenderer from source is a major breaking change that we'd rather not do, but we do not have a choice at this point. Therefore we need to take some time to warn users about this and gradually switching to the new implementation first and only then remove that class from source. This is a lengthy process but should happen well before the release of iOS 14.

I hope this addresses all your concerns about this, if not, please let me know. I'm happy to answer any questions you might have around this.

Thank you for understanding and your patience!

@jfversluis
Thanks for this brilliant answer :)

@jfversluis Thanks for your answer
Please Can you tell me how to drop the WebViewRenderer from source ?

@NehalOsama the only way to do it is to clone this XamForms repository, delete the WebViewRenderer.cs file from the Platforms.iOS project, change all references to point to the WKWebViewRenderer and build your own DLLs and use that in your app.

I would highly recommend against this. Doing this means that you cannot upgrade to versions that we will release, so you will never receive any bugfixes or anything without losing the custom made change. Or, you would need to repeat this process again for each time you want to upgrade.

If you don't mind me asking; why not wait? The message from Apple is just a warning and we will have this done well before Apple actually starts rejecting apps. There is nothing to worry about at this point.

@jfversluis
Thanks alot, Regardless removing the references and the warning, the reason is that our client insists us to integrate with another application using the webkit
I made as https://github.com/xamarin/Xamarin.Forms/issues/7323#issuecomment-527294907 ,
but how Can I make sure that my custom renderer is WKWebViewRenderer not UIWebView ?!
Is there any obvious difference between them or anything that can prove that to the client ?!

It's kind of the point that you should not see any difference between them if we did our job right 😉

I'm not sure how much proof they would need. You could dig in with inspectors or UITest stuff to dig out the actual types that are being spawned. The easiest way though is to simply set a breakpoint in your custom renderer that you have created and see if that gets hit. If it does, the WKWebView is being used. In addition you might implement a little mechanism in your custom renderer that loads a certain page from the native platform, again you can put in a breakpoint and verify that it will be using the WKWebView instead of the UIWebView.

If you want to switch all the regular WebView controls to WKWebViewRenderer without having to create a custom renderer and just use WebView instead of an inheritance, you could add this line to the AssemblyInfo.cs in your iOS project:

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

My app's binary was rejected today because of this. I am already using the WkWebViewRenderer

Dear Developer,
We identified one or more issues with a recent delivery for your app, [REDACTED]. 
Your delivery was successful, but you may wish to correct the following issues in 
your next delivery:ITMS-90809: Deprecated API Usage - Apple will stop accepting 
submissions of apps that use UIWebView APIs.
See https://developer.apple.com/documentation/uikit/uiwebview for more information.

After you’ve corrected the issues, you can use Xcode or Application Loader to upload
a new binary to App Store Connect.
Best regards,
The App Store Team

Despite this passive language ("will stop accepting"), my binary was not processed and made available for the release.

This is now critical. I can't release any new versions of my client's app.

What is the ETA for this fix?

Hi @joehanna thanks for reporting. Are you absolutely sure? The message itself says that the delivery was successful and there is no reason to assume that anything is different from when this issue was first opened. It does take some time before Apple has processed the whole binary after sending a message like this.

I see your comment is from about an hour ago, it should show up in the Developer portal by now. Would you be able to verify that it really did not go through?

Also

my binary was not processed and made available for the release.

how did you verify this? If you go to the app definition, then Activity, under All Builds, you don't see it?

Thanks for your quick reply @jfversluis. I have not received the confirmation email nor does it appear in the available builds. I guess there could be a processing backlog? In my experience, the binary is processed in under 20 minutes. I will check it again in a little while and report back.

Ah, that's a good point you're touching on there. There might be some extra activity with iOS 13 coming in and people submitting a lot of builds for that. I've just created a new version of the dummy app you can see above and submitted it as well, just to verify and see what happens.

I'll update you as soon as I see anything.

Thanks for the report in any case!

@joehanna I got the warning first and within minutes I got the second image. So, not sure what is going on with your build, but it doesn't seem to be related with the UIWebView usage

It finally came through. Sorry for the drama. Never had it take that long before. Thanks for following it up.

SDK_Bug

The issue is because of compiler is not removing unwanted class files or libraries.
Xamarin Development teams need to refer latest apple development policies.

@jfversluis We are experiencing the same issue with Xamarin.iOS projects. While this thread is under the Xamarin.Forms, is the root cause the same? Is the fix going to address both Xamarin.iOS and Xamarin.Forms?

Thank you!
CompaNova LLC

@dmitrymal there are a few causes

Xamarin.iOS will solve their cause and then we're going to build on top of that to solve ours

We have a few solutions being worked on and we will update this issue as we make progress

How come this thread is still tagged s/unverified?

No it's not @taublast 🤡

Although I appreciate this fix is a while off and not currently urgent, when it is done will it be back-ported to previous XF versions? We have a large suite of apps built in 3.4 and due to various dependency issues have always failed when trying to upgrade to XF 4.0 or above.

@1888games I think that is highly unlikely, also depending on what the eventual final fix will be.

https://github.com/xamarin/Xamarin.Forms/pull/7367 has been merged but it's only a piece to the puzzle so don't expect for the warning to disappear

It's still going to require linker fixes inside the Xamarin.Forms SDK and Xamarin.IOS SDK

• https://github.com/xamarin/Xamarin.Forms/tree/ios_linker
• And then some additional linker fixes inside the Xamarin.iOS SDK itself

So what version of XamarinForms has this fixed?

@s-bhavin-shah, we need to go through multiple stages and steps to fix this and put this away for good. Therefore this is not fixed in a certain Xamarin.Forms version at this point. I just want to reiterate that there is no reason for concern at this point. The message from Apple is just a warning for now and will be a warning for some good time to come.

By the time the warning becomes Apple rejecting apps for this reason, we will make sure to be ready. We will keep you up to date in this issue. What happened now is that we found a way to make the linker actually strip out (core) Xamarin objects that aren't used. In addition, my PR got merged that will make the WKWebViewRenderer the default.

With that in place, basically the last step is to release the "iOS linking" solution. When that happens the WKWebViewRenderer being the default and the WebViewRenderer not being used in your code anymore should result in being dropped from the resulting binary that is sent to Apple. That being said; releasing the iOS linking solution is easier said than done and will take some more time.

The upside here is that we probably are not going to have to go with the full breaking change solution, but we can gradually transition everyone into this solution.

Hope this will answer all your questions at this time. If not, please let me know!

When deprecating UIWebView and replacing it with WkWebView you should consider this issue
https://github.com/xamarin/Xamarin.Forms/issues/8028

You can break people's apps if you just replace UIWebView with WkWebView

@Mikilll94 While the point is valid, the simple fact is that Apple will begin to reject binaries that still use UIWebView. So even if Xamarin did nothing, it would be a breaking change anyway because Apple will (probably in the next 9 months) not let you update your app without making that change anyway.

@cabal95
That's right.

But I wanted to show that there is an issue with WkWebView which is very crucial and will affect many developers and right now there is no workaround for it.

Same Issue ! Any perfect work Around?

Hey @samirgcofficial thanks for reporting your findings. Did you see the comment that we are referring to all the way at the top: https://github.com/xamarin/Xamarin.Forms/issues/7323#issuecomment-542363338?

That should explain the current status pretty much :)

Summary: there is no workaround or solution right now, we are working on it. But this message from Apple is just a warning and you should be able to submit your apps without any problems, just this warning message.

If there are any questions, please let me know!

@jfversluis @samirgcofficial
As per my experience, Apple no longer accepts any app that shows UIWebView in its binary. We are unable to send our Xamarin apps to App Store any more. Thus, it is not only a warning message, it is very important issue.
If on the other hand you have a solution on how to publish our apps, Please let us know how?

@JawadJaber Yes, It's a serious issue! I can't do external testing of my app in app store for test flight. But Internal testing of app is possible and this WebView never affect's for internal testing.
Scenario was to generate external link and share which can't be done in Test Flight. Any solution ?

@JawadJaber if you are getting a different message from Apple that says they rejected your binary rather than just warning then please post a screenshot or something to give more details. I successfully submitted a binary to Apple on Friday with no issue other than the warning email.

I just submit a binary and I got warning e-mail only

@JawadJaber @samirgcofficial could you please tell me why you think your binary is rejected because of this reason? We have no reason to think anything other than this is still a warning. A lot of people are confirming this and the warning text in the e-mail message has not changed since this issue was created.

We agree that this is a very important issue, that is why we are working hard on a solution and we are as clear and transparent as we could be at this point.

Earlier in this thread there was another person that thought his binary was rejected but processing just took a bit longer. Could it be that this is also the case for you?

Ok, I admit it is working properly now with Apple.
Although, 3 weeks back it was rejected, and I contacted App Store support team and they said the same (their policy).
But now it is working. I think Apple just changed their policies for this case. Thank you @jfversluis , @martijn00 @cabal95

Ok, I got another message from app store team that i was restricting all the user's to access app and allowing certain region people for OTP verification using TWILO. I should exclude restriction's that's all and app is on beta test right now :). That's all. Thank's everyone.

same issues

it's pretty hard to explain customers that our app is absolutely okay, it's just a warning, etc((

I totally understand @YuliaLoyko. Unfortunately we’re moving as fast as we can.

waiting for 4.4

@prasannamca1107 just to be clear and not get your hopes up. This is not going to be fixed in 4.4. We are also dependant on a change in Xamarin.iOS here, this cannot be fixed just by the Xamarin.Forms team.

On the bright side, I have seen a working fix, so like I mentioned: we are working on it, but it will take a while before everything lines up and we can put it in your hands.

So far, still nothing to worry about, the message from Apple is still just a warning!

I was following a thread in xamarin forum and found this link which should work i think.

no same warning i tried

@softsan, thanks for sharing! Unfortunately, that is not a solution currently. At this time, there is no (easy) solution. The only thing you could do, which I highly recommend against, is building your own Xamarin.Forms packages with the UIWebViewRenderer deleted from the solution.

We are still working hard on a solution, no worries! :)

I submitted a new app last Friday, I got the same warning but was just that: A warning.
App is approved and listed in the app stores without any problem.

@jfversluis , @softsan I wrote my own renderer for the WebView, which returns a WKWebView. I have tested the code and published it to the store and still receive the warning. My renderer follows the typical pattern for a renderer but here is a brief snippet of the relevant code:

if ( Control == null)
{
_contentController = new WKUserContentController();
var frame = UIApplication.SharedApplication.Delegate.GetWindow().Bounds;
var cgRect = new CoreGraphics.CGRect(frame.X, frame.Y, frame.Width, frame.Height);
var config = new WKWebViewConfiguration { UserContentController = _contentController };
_wKWebView = new WKWebView(cgRect, config)
{
NavigationDelegate = new WKNavigationDelegate()
};

                    SetNativeControl(_wKWebView);
                }

There is only one place in my code that uses a web browser and I have debugged this code and inspected the data types and verified it is correct yet I received the error from Apple. I have submitted a review contention to the review team and am waiting to hear back.

@seanstilson it will be of no use. As indicated earlier in this issue, even if you create a custom renderer that uses the WKWebView the UIWebViewRenderer will still be included in the Xamarin.Forms binaries because of how it works right now. We are working on changing that, but until we do, there is nothing you can do to change this at this time.

Apple will probably simply tell you there is a reference to UIWebView. Not in your code, but through the Xamarin.Forms code still inside your app.

Having this said; we will make sure to fix it one way or the other before Apple really stops accepting binaries because of this.

Sorry I missed the post earlier about the UIWebViewRenderer being built
into the binaries @jfversluis, my bad. Thanks for the response!

On Thu, Nov 14, 2019 at 11:54 AM Gerald Versluis notifications@github.com
wrote:

@seanstilson https://github.com/seanstilson it will be of no use. As
indicated earlier in this issue, even if you create a custom renderer that
uses the WKWebView the UIWebViewRenderer will still be included in the
Xamarin.Forms binaries because of how it works right now. We are working on
changing that, but until we do, there is nothing you can do to change this
at this time.

Apple will probably simply tell you there is a reference to UIWebView. Not
in your code, but through the Xamarin.Forms code still inside your app.

Having this said; we will make sure to fix it one way or the other before
Apple really stops accepting binaries because of this.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/xamarin/Xamarin.Forms/issues/7323?email_source=notifications&email_token=AMVYZVVKIGZKMMH5XOS2QATQTWGF5A5CNFSM4ISLFU32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEECWXMI#issuecomment-554003377,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AMVYZVUT5A73R4SXSQFRDMDQTWGF5ANCNFSM4ISLFU3Q
.

@seanstilson don't worry about it. There is a lot of action here, I can imagine you miss something :)

Hey friends, we will lock this issue for now while we await results from the Xamarin.iOS team before we can proceed. This way we will be able to track this issue properly, and people encountering this will be able to find the most relevant info directly instead of going to have to go through all the conversation in here. Whenever there is something new to report, we will definitely will.

For a good summary of what is going on please read this comment here: https://github.com/xamarin/Xamarin.Forms/issues/7323#issuecomment-532228577

The latest progress at this time can be found here: https://github.com/xamarin/Xamarin.Forms/issues/7323#issuecomment-542363338

The gist of it is: we are working on the issue in a way that will be backwards compatible and we will be ready, one way or the other, before Apple actually starts rejecting apps because of this.

Right now, the only thing is that you get a warning message from Apple which can safely be ignored for now.

Thank you for your understanding and patience!

Small update on this: #8001 has been merged as a first step to the proposed fix. However, this does not mean the issue will be gone in an upcoming version yet.

As we have mentioned before, there is also something that needs to be changed in Xamarin.iOS for this to work. Whenever they will do that, the right Xamarin.iOS version together with this code (starting from 4.5), this will finally go away.

To be perfectly clear: version 4.5 of Xamarin.Forms alone will NOT fix this issue. Whenever the full fix is on the horizon I will be sure to update this again.

Thanks!

Apple has released a short statement where they give some more clarity on their plans for deprecating UIWebView. I think the most important piece is this:

The App Store will no longer accept new apps using UIWebView as of April 2020 and app updates using UIWebView as of December 2020.

That means we still have some time to come up with a solution, whatever it will be. In the meantime we have been looking into our preferred solution. Together with the Xamarin.iOS team we have managed to submit an app to the store that does not trigger the warning while still remaining backwards compatible. That means not dropping the (now) legacy WebViewRenderer. We are still deciding if that is _the_ solution based on a couple of factors, but we are still working on it and will make sure we are ready. At least now we know when to be ready 😄thank you for your patience!

Great news everyone! There is a final fix that should be out for you to use soon.

It does need a little bit of work on your side, I am currently working on a bit of documentation that describes what that is. Don't worry, it's not that complicated!

Whenever that is live and all the bits are available for you as well, I will post it here. No solid promises, but it should be rather soon and well before the April deadline.

Again, thank you for sticking with us on this!

Solution is here!

All the bits are in place, solution time! TL;DR: all is described in this piece of documentation here.

Make sure you are using the latest Visual Studio (for Mac) on the stable channel, that should put you on the right path. At the moment, you will need to use the Xamarin.Forms 4.5-pre1 preview release. I understand that this might not be an option for all of you, but rest assured, the stable package will be out well before the deadline. Stable 4.5 is planned mid to end of February.

Lastly, put the --optimize=experimental-xforms-product-type flag into your iOS additional mtouch arguments setting and you should get rid of the deprecation warning by Apple. If you don't have any references of your own to UIWebView of course 🙂

I would like to ask you to try this at your earliest convenience. Maybe not to release an actual new version to the store based on the Forms preview package, but at least upload a build to verify that this solution works correctly. Whenever you do, you can just update to the 4.5 stable package and release a new version with confidence.

If you do run into anything with this solution, please feel free to reach out to me directly (gerald.versluis [a with a long tail] microsoft.com) or open a new issue on the repository. Of course positive feedback is always appreciated as well 😉

Thank you again!