다음을 통해 공유

Xamarin.iOS 13.16 Release Notes

  • 아티클

System Requirements | What's New | Known Issues | Blogs | Open Source

To see installation instructions for both Visual Studio for Mac and Visual Studio 2019, please visit Installing Xamarin

Requirements

  • 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 UIWebView won't be accepted as of April 2020
  • Application updates using UIWebView won'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.

Detection

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:1502 would report errors if any references are found in pre-linked assemblies
  • -warnaserror:1503 would 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:1502 would not report warnings if any references are found in pre-linked assemblies
  • -nowarn:1503 would 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.

Indirect usage

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.

Alternatives:

  1. If you're using Xamarin.Forms, then read this blog post.
  2. 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.
  3. See special case if you cannot change the managed linker settings.

Special cases

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 WKWebView if 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.

Release History

This version of Xamarin.iOS corresponds to our 16.5 (d16-5) milestone.

  • March 31, 2020 - Xamarin.iOS 13.16.0.11
  • March 12, 2020 - Xamarin.iOS 13.16.0.0

You can learn more about how we ship our releases in the Visual Studio 2019 Release Rhythm document.

March 31, 2020 - Xamarin.iOS 13.16.0.11

The following frameworks have been updated to released Xcode 11.4.

March 12, 2020 - Xamarin.iOS 13.16.0.0

This preview includes the following updates to existing frameworks (all API updated to beta 3 unless noted)

Updated frameworks

Issues

  • 7962 - [CoreFoundation] Fix TypeInitializationException in OSLog
  • 7786 - [mtouch] Auto-change settings where they are honored for extensions
  • 7983 - [msbuild] Add support for Metal in the simulator

Known Issues

Using an older Xcode version

Using an older Xcode version (than the one mentioned in the above requirements) is often possible. For more information see the following documentation.

API Diff

The following documents contains a complete list of the API changes since the Xamarin.iOS 13.14 stable release:

Integrated Mono Features/Fixes

Xamarin.iOS uses a customized runtime and base class libraries (BCL) from Mono 6.8 Commit df42020f

Feedback welcome

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.

Open Source

Xamarin.iOS is based on the following open-source repositories: