Xamarin.iOS 13.16 Release Notes
To see installation instructions for both Visual Studio for Mac and Visual Studio 2019, please visit https://docs.microsoft.com/xamarin/get-started/installation
- The latest features and APIs require Xcode 11.4 and the bundled iOS, tvOS and watchOS SDKs
- Apple Xcode 11.4 requires a Mac running macOS 10.15.2 (Catalina) or newer
- Visual Studio 2019 or Visual Studio for Mac
What's New in this Release
Support for Xcode 11.4
For more information you can consult the Xcode 11.4 release notes from Apple.
Support for iOS 13.4 and iPadOS 13.4
For more information you can consult the release notes from Apple:
See our API diff to browse the latest changes.
Help with UIWebView deprecation
Developers who submitted iOS applications in the last six months (or so) might have received this warning from the App Store.
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.
Back then little was known when this warning would become an actual error - stopping submissions for the affected applications. We now know that
- New applications using
UIWebViewwon't be accepted as of April 2020
- Application updates using
UIWebViewwon't be accepted as of December 2020
Deprecations of APIs are common. Xamarin.iOS uses custom attributes to signal those APIs (and suggest replacements when available) back to the developers. What is different this time, and much less common, is that the deprecation will be enforced by Apple's App Store at submission time.
Sadly removing the
UIWebView type from
Xamarin.iOS.dll is a binary breaking change. Such change will break existing 3rd party libraries, including some that might not be supported or even re-compilable (for example, closed source) anymore. This would only create additional problems for developers. As such we are not removing the type yet.
If you have not recently submitted an iOS application to the Apple App Store, you might wonder if this situation applies to your application(s).
To find out, you can add
--warn-on-type-ref=UIKit.UIWebView to your project's Additional mtouch arguments. This will warn of any reference to the deprecated
UIWebView inside your application (and all its dependencies). Different warnings are used to report types before and after the managed linker has executed.
The warnings, like others, can be turned into errors using
-warnaserror:. This can be useful if you want to ensure a new dependency to
UIWebView is not added after your verifications. For example
-warnaserror:1502would report errors if any references are found in pre-linked assemblies
-warnaserror:1503would report errors if any references are found in post-linked assemblies
You can also silence the warnings if either the pre/post linking results are not useful. For example
-nowarn:1502would not report warnings if any references are found in pre-linked assemblies
-nowarn:1503would not report warnings if any references are found in post-linked assemblies
How to fix
Every application is unique. Removing
UIWebView from your application can require different steps depending on how and where it is used. The most common scenarios are:
There is no use of
UIWebView inside your application
Everything is fine. You should not have warnings when submitting to the AppStore. Nothing else is required from you.
Direct usage of
UIWebView by your application
Start by removing your use of
UIWebView, for example, replace it with the newer
WKWebView (iOS 8) or
SFSafariViewController (iOS 9) types.
Once this is completed the managed linker should not see any reference to
UIWebView and the final app binary will have not trace of it. You're back to the previous section, that is, everything is fine.
UIWebView can be present in some third party libraries, either managed or native that is used by your application.
Start by updating your external dependencies to their latest versions since this situation might already be solved in a newer release. If not, contact the maintainer(s) of the libraries and ask about their update plans.
- If you're using Xamarin.Forms, then read this blog post.
- Enable the managed linker (on the whole project or, at least, on the dependency using
UIWebView) so it might be removed, if not referenced. That would solve the problem but might required additional work to make your code linker-safe.
- See special case if you cannot change the managed linker settings.
Applications cannot use the linker (or change its settings)
If for some reason you are not using the managed linker (for example, Don't link) then the
UIWebView symbol will remain in the binary app you submit to Apple and might cause rejections.
A forceful solution is to add
--optimize=force-rejected-types-removal to your project's Additional mtouch arguments. This will remove traces of
UIWebView from the application. However any code that refers to the type will not work properly (expect exceptions or crashes). This should be used only if you're sure that the code is not reachable at runtime (even if it was reachable through static analysis).
Support for iOS 7.x (or earlier)
UIWebView has been part of iOS since forever (2.0). However the most common replacements are
WKWebView (iOS 8) and
SFSafariViewController (iOS 9). That might leave you with no good option if your application still supports older iOS versions. You might consider:
- making iOS 8 your minimum target version (a build time decision); or
- only use
WKWebViewif running on iOS 8+ (a runtime decision)
Applications not submitted to Apple
If your application is not submitted to Apple, then this deprecation is not different of any other API deprecation. In other words: you should plan to move away from deprecated API since they can be removed in future OS releases. However you can do this transition using your own time table.
This version of Xamarin.iOS corresponds to our 16.5 (
- March 31, 2020 - Xamarin.iOS 18.104.22.168
- March 12, 2020 - Xamarin.iOS 22.214.171.124
You can learn more about how we ship our releases in the Visual Studio 2019 Release Rhythm document.
March 31, 2020 - Xamarin.iOS 126.96.36.199
The following frameworks have been updated to released Xcode 11.4.
March 12, 2020 - Xamarin.iOS 188.8.131.52
This preview includes the following updates to existing frameworks (all API updated to beta 3 unless noted)
- 7858 - AuthenticationServices
- 8049 - AutomaticAssessmentConfiguration
- 7859 - AVFoundation
- 7861 - CarPlay
- 7860 - CallKit
- 7862 - ClassKit
- 7863 - Contacts
- 7864 - CoreBluetooth
- 7865 - CoreGraphics
- 7867 - CoreLocation
- 7868 - CoreText
- 7869 - GameKit
- 8025 - Intents
- 7884 - LocalAuthentication
- 8055 - Metal
- 8041, 7885 - PassKit
- 7886 - SafariServices
- 7963, 7887 - UIKit
- 7964 - VideoSubscriberAccount
- 8043 - VideoToolbox
- 7965 - WatchKit
- 8054 - WebKit
- 7962 - [CoreFoundation] Fix
- 7786 - [mtouch] Auto-change settings where they are honored for extensions
- 7983 - [msbuild] Add support for
Metalin the simulator
Using an older Xcode version
The following documents contains a complete list of the API changes since the Xamarin.iOS 13.14 stable release:
Integrated Mono Features/Fixes
Your feedback is important to us. If there are any problems with this release, check the Xamarin.iOS Forums and Xamarin Mac/iOS GitHub Repository for existing issues. If you do not find any matching issue, please feel free to start a new discussion and report an issue.
Xamarin.iOS is based on the following open-source repositories: