Partajați prin


Apple Platform (iOS and Mac)

Code Sharing

For elements of your code that have no user interface elements the best way to share code between iOS and Mac is still the use of Portable Class Libraries.

For code that has to do some user interface work and yet, you want to share, you should use Shared Projects which allow you to place code to share in a single project and have it compiled with both Mac and iOS when referenced.

Unified API

The Unified API for iOS and Mac projects uses the same namespaces for frameworks so that the same code file can be used across both platforms, for seamless code-sharing. It also enables both 32 and 64 bit builds. The Unified API has been the template default since early 2015, and is recommended for all new projects - only Unified API projects can be submitted to the App Store.

Classic APIs

Note

Classic Profile Deprecation: As new platforms are added in Xamarin.iOS we are starting to gradually deprecate features from the classic profile (monotouch.dll). For example, the non-NRC (new-ref-count) option was removed. NRC has always been enabled for all unified applications (i.e. non-NRC was never an option) and has no known issues. Future releases will remove the option of using Boehm as the garbage collector. This was also an option never available to unified applications. The complete removal of classic support is scheduled for fall 2016 with the release of Xamarin.iOS 10.0.

The original (non-Unified) Xamarin.iOS and Xamarin.Mac APIs made code-sharing more difficult because native frameworks had either MonoTouch. or MonoMac. namespace prefixes. We provided some empty namespaces that allows developers to share code by adding using statements that reference both MonoMac and MonoTouch namespaces on the same file, but this was a little ugly. The Classic API should only continue to be used in legacy apps that are internally distributed (upgrading to the Unified API is recommended).

Updating from Classic to the Unified API

There are detailed instructions for updating any application from the Classic to the Unified API.

Binding Objective-C Libraries

Xamarin lets you bring native libraries into your apps with bindings. This section explains:

  • how bindings work,
  • how to manually build a binding project that lets you bring Objective-C code into Xamarin, and
  • how to use our Objective Sharpie tool to help automate the process.

Native References

Mac/iOS Native Types

To support 32 and 64 bit code transparently from C# and F#, we are introducing new data types. Learn about them here.

Building 32 and 64 bit apps

What you need to know to support 32 and 64 bit applications.

Working with Native Types in Cross-Platform Apps

This article covers using the new iOS Unified API Native types (nint, nuint, nfloat) in a cross-platform application where code is shared with non-iOS devices such as Android or Windows Phone OSes. It provides insight into when the Native types should be used and provides several possible solutions to cases where the new type must be used with cross-platform code.

HttpClient Stack and SSL/TLS Implementation Selector

The new HttpClient Stack Selector controls which HttpClient implementation to use in your Xamarin.iOS, Xamarin.tvOS and Xamarin.Mac app. You can now switch to an implementation that uses iOS’s, tvOS's or OS X's native transports (NSUrlSession or CFNetwork depending on the OS).

SSL (Secure Socket Layer) and its successor, TLS (Transport Layer Security), provide support for HTTP and other network connections via System.Net.Security.SslStream. The new SSL/TLS implementation build option switches between Mono’s own TLS stack, and one powered by Apple’s TLS stack present in Mac and iOS.