UIWebView Deprecation and Xamarin.Forms
Gerald Versluis
A little while ago, Apple started sending out warning messages about the UIWebView deprecation. This has not gone unnoticed by our Xamarin.Forms users, who directly created an issue for it. Today we have some great news to share: we 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.
The History of UIWebView
UIWebView has already been around since iOS 2.0 but has been deprecated since iOS 8.0. Its successor, WKWebView, of course, does the same thing functionally but has some advantages over the old UIWebView.
As soon as the UIWebView deprecation became known, the Xamarin.Forms team worked to make a replacement WKWebViewRenderer. While it has been available in Forms for a long time now, the default was still the UIWebViewRenderer.
Shortly after the introduction of iOS 13, Apple decided to send out warning messages about the UIWebView deprecation. The warning would read:
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.
This warning was still a warning and would not prevent you from publishing your app at the time. A few months after this, Apple announced that as of April 2020 they reject new apps still referencing UIWebView. For updates to apps the deadline is December 2020. Of course, we want to be ready well before then, and we are.
Maintain Backwards Compatibility for Xamarin.Forms
With Xamarin.Forms we 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 pretty 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.
Because of this, we thought the solution would be to simply switch the default renderer to the WKWebViewRenderer. By doing that, there would be no reference to the UIWebView anymore and it would be taken out by the linker.
While working on this, we discovered that the linker does a fantastic job, but the Xamarin.Forms binary was excluded from linking by default. That would mean as long as the UIWebViewRenderer file would exist in our codebase, ultimately apps would be rejected.
This was a problem, because if we want to keep up our backwards compatibility game, we couldn’t just delete the UIWebViewRenderer. This would potentially break custom renderers or other code that referenced this class implemented by Xamarin.Forms users. Therefore, we went looking for another solution.
Xamarin.iOS Team to the Rescue
During our quest for a solution we had multiple options. For example: making stubs or rewriting the UIWebViewRenderer to use WKWebView underneath. The most obvious option, however, would be to find out if we could make the linker work for Xamarin.Forms as well.
We have worked closely with the Xamarin.iOS team to make that happen. On top of that, we are proud to say that we have a solution that does exactly that.
Because Xamarin.Forms has 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.
Prevent App Store Rejection, Today!
The solution only involves three steps:
- Use the right versions of Xamarin.Forms and Xamarin.iOS.
- Add a flag to the build configuration.
- Build and submit your app to the App Store and celebrate!
On the Xamarin.Forms side we also had to make some changes to make all this work correctly. These new changes are part of Xamarin.Forms 4.5, including the pre-releases. Make sure that you are using the Forms 4.5 or newer NuGet package in your projects.
You also need to make sure that you are using Xamarin.iOS 13.10.0.17. You can check this from Visual Studio. This version of Xamarin.iOS is included with Visual Studio for Mac 8.4.1 and Visual Studio 16.4.3 and up.
With that in place, you can simply go to your iOS project, open the project properties and add this flag in the additional mtouch arguments field: --optimize=experimental-xforms-product-type this flag works together with the Linker Behavior set to SDK Only or All. If for any reason you see errors when setting the Linker Behavior to All, this is most likely a problem within the app code or a 3rd party library that is not linker safe. For more information on the linker, please refer to the docs.
In the screenshot below you can see the end result in Visual Studio for Mac.
This setting can be applied per build configuration so make sure that you put it in the right one. That will probably be the iPhone/Release build configuration which is typically used for distribution builds. Also make sure the Linker behavior is set to either SDKs only or Link All.
UIWebView Deprecation Fixed
That’s it! Now create a new build, submit it to the App Store and all is good.
All of this is described with a bit more detail in the documentation.
Light
Dark
72 comments
Hi Gerald,
I’m still having a problem about making this to work, I followed everything these are my versions:
– Visual Studio for Mac 8.5.4 (build 12)
– Xamarin.Forms v4.5.0.495
– Xamarin.iOS v13,16.0.13
– Added `–optimize=experimental-xforms-product-type` on mtouch on Release | iPhone configuration with linker behavior set to “Link All”.
– I did not add the Xamarin.ios.MaterialComponents some people are talking about nor use the Appcenter build mechanism, although I had few appcenter related nugets, I only use archive and publish built in Visual Studio for Mac to create an IPA and upload it to itunesconnect.
– I am also using WKWebView in my code through a ViewRenderer
Hey Jelmar,
Sorry about that! From all the things you mentioned it looks pretty good. The only thing is:
> I did not add the Xamarin.ios.MaterialComponents…
That is not the only NuGet that might have a reference to UIWebView.
In any case, send me an email, my address is in other comments on this page and we will figure it out 🙂
Ok will do, thank you for your reply, I will send further details in the email, but quick question tho, does –warn-on-type-ref=UIKit.UIWebView detect every thing that reference the UIWebView including the installed nuggets?
The problem with Xamarin.Forms.Visual.Material appears to have been resolved in a recent release. Updating both Xamarin.Forms and Xamarin.Forms.Visual.Material to 4.6.0.726 (and applying the steps in the post) has resolved the problem for me.
Hey Gary!
Yes, we’ve updated the dependency there. So when using 4.6 of Visual.Material everything should be good there 🙂
Thanks!
Hello,
I am trying to follow your recommendations here but it does not help me out.
Xamarin forms 4.6.0.726, my linker, and built set up according to your recommendation. I am not using neither UIWebView nor WKWebView but my app is still getting rejected because of ITMS-90809: Deprecated API Usage.
One thing I noticed when archiving my ipa (despite linker to be set “Link all”.
MTOUCH : warning MT2003: Option ‘–optimize=experimental-xforms-product-type’ will be ignored since linking is disabled
MTOUCH : warning MT2003: Option ‘–optimize=force-rejected-types-removal’ will be ignored since linking is disabled
MTOUCH : warning MT1502: One or more reference(s) to type ‘UIKit.UIWebView’ already exists inside ‘Xamarin.Forms.Platform.iOS, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null’ before linking
MTOUCH : warning MT1503: One or more reference(s) to type ‘UIKit.UIWebView’ still exists inside ‘Xamarin.Forms.Platform.iOS, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null’ after linking
Thanks,
Lukas
Any suggestions on how to troubleshoot it?
Thanks
Lukas
Strange that it wasn’t mentioned in this article, but here https://docs.microsoft.com/en-us/xamarin/ios/release-notes/13/13.16#help-with-uiwebview-deprecation is mentioned that you can use –warn-on-type-ref=UIKit.UIWebView additional mtouch argument to find which DLLs are using UIWebView. For example Firebase is using that too in older versions https://github.com/firebase/firebase-ios-sdk/issues/3722 and should be also updated.
Hi Lukas,
Sorry it doesn’t seem to work for you 🙁 Did you also look into the links that are mentioned in earlier comments? I know it’s a lot to take in. If you’re sure that you got the linker, XF version and flag in place, the last option would be that you are using NuGets that still have a reference. Make sure to check and upgrade those as well.
If you can’t figure it out, find my email and reach out.
I added the argument with “linking SDKs only” as suggested. Unfortunately, I’ve got a new error: Failed to parse altool output:Failed to parse PList data type.
Do you have any idea of what caused this issue? Even my Xcode is a recent version.
Currently I am using the following specs:
VS:8.5.4.
Xamarin.iOS:13.17.0.13
Xamarin.form: 4.6.X.
Thanks in advance.
Your problem should have nothing to do with WebView. You can try to compile your C# file to see if it’s sqllite？
Update your build number for this one…
Hi, Gerald Versluis
I have modified everything like this document; also i have removed every Webview controls from my Xamarin Forms project for testing purpose.
versions XamarinForms 4.6.0.772 Xamarin.iOS 13.10.0.17 . When i try to upload again i’m getting the same error “ITMS-90809: Deprecated API Usage – New apps that use UIWebView are no longer accepted. Instead, use WKWebView for improved security and reliability. Learn more (https://developer.apple.com/documentation/uikit/uiwebview).”
I’m using these plugis also. is it because of this
Xamarin.Google.ios.Signin
Xamarin.Facebook.iOS
Plugin.GoogleClient.
I have uploaded the ipa almost 10 times….
Please help me……
Hi Liju,
Depending on what versions you are using of that plugins that might be the problem yes.
There are a lot of different links and things you can try in the comments here as well. What did you try already? And what did you find?
If you can’t seem to find it, please reach out to me by email and we’ll figure it out.
Hi Gerald,
We’ve set Linked behavior to Link All and mtouch arguments as instructed but we still get the same email from Apple with “ITMS-90809: Deprecated API Usage” issue when we try to publish the app.
We don’t use WebView in our project and all Nuget packages are updated to the latest versions.
Visual Studio 2019 Version 16.5.4
Xamarin Forms 4.6.0.800
Xamarin.iOS and Xamarin.Mac.SDK 13.16.0.13
Any help would be appreciated as this is preventing us from releasing the app. Thanks
Sorry to hear that Milos!
Did you read through all the comments here and links that are in there?
Other things that might be important are:
* Do you have any NuGets that need updating which might still be referencing the UIWebView
* Are you publishing your app through a pipeline? Are you sure that the same configuration is used there as where you configured the mtouch arguments?
* Delete your obj and bin folders from all folders in your solution on disk to make sure not any caching is happening
Did you try the forceful flag from this link: https://docs.microsoft.com/en-us/xamarin/ios/release-notes/13/13.16#applications-cannot-use-the-linker-or-change-its-settings
And what happens if you follow this suggestion from this comment here: https://github.com/xamarin/Xamarin.Forms/issues/9823#issuecomment-624655801
What is the output from that?
If that doesn’t fix it find my email address on my GitHub profile and reach out.
Thanks!
Hi Gerald, thank you for the quick reply!
We have a CI/CD pipeline on AppCenter so this is where we are actually seeing this issue. I realised that if I publish directly from Visual Studio for Mac, then there are no issues and Apple approves the build.
Do you maybe have an idea what we can do to fix this so that we can switch back to CI/CD and AppCenter?
Thanks,
Milos
Sure thing Milos!
What I think is going on is that the wrong Xamarin.iOS version is selected on App Center. If you go into the build configuration you should be able to select which version is used. Make sure that is 13.10+ I think at this time I would even recommend 13.16.
Can you confirm that is the case?
Hi, Milos and Gerald!
I’m having the same problem, manually I publish without problems but in the app center the binary is rejected. Do you know how we can send mtouch argument (–optimize = experimental-xforms-product-type) using the app center?
Thiago,
That setting is saved in your csproj file. So as soon as you commit it it should be part of your build in App Center.
Hi Gerald,
Sorry for late a reply – I don’t get notified when someone replies to my comments.
I’ve changed the SDK version to the latest (13.16) and that has indeed solved the problem! No more issues when we publish to App Store.
Thanks so much for your help!
Cheers,
Milos
I had done like you said in the documentation, I added this(“–optimize=experimental-xforms-product-type”) in argument and choose Link behavior – “All” and I choose to Build Configuration – “AppStore” or “Release” after submitting an application to AppStore, Apple return error “ITMS-90809”, please help to resolve this issue.
Visual Studio 2019 version: 16.5.4
Visual Studio for Mac: 8.6
Xamarin.Forms version: 4.6.0.726
Xamarin.iOS version: 13.18.1.31
Thanks for reading and support.
Hi Manvel,
Did you also configure the flag for AppStore and Release configurations?
Are you using any NuGets that might still hold a reference to UIWebView?
Yes, I configured the flag and try with both AppStore and Release.
I think there are only two packages that can have a reference to UiWebView, Xamarin.Google.iOS and Xamarin.Facebook.iOS
Make sure that you have installed the latest packages of both of these packages. Delete the bin & obj folders from your filesystem and do a full rebuild to make sure not any kind of caching is going on.
Thank you very much for the response, now I will try to do it, and let you know.
Hi Gerald,
Thanks a lot for the really informative article.
I find myself in the position where I’m not able to easily upgrade my version of Xamarin and indeed spent many hours and lost a lot of hair in the attempt.
Instead I turned to your second suggestion of compiling my own version of Xamarin. This was much easier than expected and after only 40 minutes I had a working build of my app up on the Apple store with minimum disruption to my own code base.
I highly recommend others do the same thing and to help I’ve published an article on Linked-In with step by step instructions, screenshots and code samples to show exactly what I did. I also describe some of the issues I found upgrading including the black screen problem reported by Andrew.
Thanks again and stay safe.
Graeme
Hi Graeme!
I’m glad to hear this unblocked you! I would love to hear if there is anything we can do to make upgrading the stock Forms version for your app. I’m curious why that would not be an option for you.
While you might recommend building a custom version of Forms, I do want to reiterate that I highly recommend against it. It will make upgrading to future versions even harder. It’s a slippery slope to now implement more custom features and other things and keep rolling with that custom version. Which is fine, if that is the way you want to go, but going back to the regular, supported and maintained version will become harder and harder.
Just a word of warning. 🙂 Glad it worked for you!
Hi Gerald,
Thanks a lot for the reply.
My problem that my project has been running for a couple of years with multiple apps being spun from the same code base. What I really need in the short term (really for the rest of this year) is stability in the code and to minimize the amount of regression testing.
The resources provided by yourself and Microsoft are fantastic and there’s no doubt I’ll be able to sort out the various issues with upgrading but the disruption right now in doing so is too much and I imagine others are in the same boat.
With the solution I’ve presented I’ve only modified a single assembly rather than the entire Forms and the code that’s been removed isn’t even used by my app so the impact on my code is pretty much 0.
Its a testament to the good work that you guys have done including the standard of the code that I’ve been able to do this so quickly and to be sure my next project already in the pipes is with 4.7 and 2019 (though I do wish they’d bring back the UML designer 🙂 ).
Thanks again and enjoy the weekend
G