통합 된 API 개요Unified API Overview

Xamarin의 통합 API Mac 및 iOS 지원 32 비트 및 64 비트 응용 프로그램 간에 동일한 이진 파일을 사용 하 여 코드를 공유할 수 있습니다.Xamarin's Unified API makes it possible to share code between Mac and iOS and support 32 and 64-bit applications with the same binary. 통합 API는 새 Xamarin.iOS 및 Xamarin.Mac 프로젝트에는 기본적으로 사용 됩니다.The Unified API is used by default in new Xamarin.iOS and Xamarin.Mac projects.


앞에 통합 API를 사용 하 여 Xamarin 클래식 API는 더 이상 사용 되지 않습니다.The Xamarin Classic API, which preceded the Unified API, has been deprecated.

  • 클래식 API (monotouch.dll)를 지원 하기 위해 Xamarin.iOS의 마지막 버전 9.10 Xamarin.iOS 했습니다.The last version of Xamarin.iOS to support the Classic API (monotouch.dll) was Xamarin.iOS 9.10.
  • Xamarin.Mac을 클래식 API를 계속 지원 되지만 더 이상으로 업데이트 됩니다.Xamarin.Mac still supports the Classic API, but it is no longer updated. 되지 하므로 개발자가 응용 프로그램 통합 API로 이동 해야 합니다.Since it is deprecated, developers should move their applications to the Unified API.

클래식 API 기반 앱 업데이트Updating Classic API-based Apps

플랫폼에 대 한 관련 지침을 따르세요.Follow the relevant instructions for your platform:

코드를 Unified API로 업데이트하는 팁Tips for Updating Code to the Unified API

마이그레이션하는 응용 프로그램에 관계 없이, 체크 아웃 이러한 팁 통합 API로 성공적으로 업데이트할 수 있습니다.Regardless of what applications you are migrating, check out these tips to help you successfully update to the Unified API.

라이브러리 분할Library Split

이 시점에서 두 가지 방법으로 Api는 표시 됩니다.From this point on, our APIs will be surfaced in two ways:

  • 클래식 API: 32 비트 (전용) 제한 및 노출 된 monotouch.dllXamMac.dll 어셈블리입니다.Classic API: Limited to 32-bits (only) and exposed in the monotouch.dll and XamMac.dll assemblies.
  • API 통합된: 사용할 수 있는 단일 API 사용 하 여 모두 32 비트 및 64 비트 개발을 지원 합니다 Xamarin.iOS.dllXamarin.Mac.dll 어셈블리입니다.Unified API: Support both 32 and 64 bit development with a single API available in the Xamarin.iOS.dll and Xamarin.Mac.dll assemblies.

즉, 엔터프라이즈에 대 한 새로운 Api를 개발자 (없습니다 대상으로 하는 앱 스토어), 영원히 또는 있습니다 유지 유지는 대로 기존 클래식 Api를 사용 하 여 계속 수 있습니다 업그레이드할 수 있습니다.This means that for Enterprise developers (not targetting the App Store), you can continue using the existing Classic APIs, as we will keep maintaining them forever, or you can upgrade to the new APIs.

Namespace 변경Namespace Changes

Mac 및 iOS 제품 간에 코드를 공유 마찰을 줄이기 위해 제품의 Api에 대 한 네임 스페이스를 변경 합니다.To reduce the friction to share code between our Mac and iOS products, we are changing the namespaces for the APIs in the products.

에서는 삭제 하 고 접두사 "MonoTouch" iOS 제품 "MonoMac"의 데이터 형식에 따라 Mac 제품에서.We are dropping the prefix "MonoTouch" from our iOS product and "MonoMac" from our Mac product on the data types.

이 간편 하 게 조건부 컴파일을 사용 하지 않고도 Mac 및 iOS 플랫폼 간에 코드 공유 및 소스 코드 파일의 맨 위에 있는 노이즈를 줄일 수 있습니다.This makes it simpler to share code between the Mac and iOS platforms without resorting to conditional compilation and will reduce the noise at the top of your source code files.

  • 클래식 API: 네임 스페이스를 사용 하 여 MonoTouch. 또는 MonoMac. 접두사입니다.Classic API: Namespaces use MonoTouch. or MonoMac. prefix.
  • API 통합된: 네임 스페이스 접두사가 없는Unified API: No namespace prefix

런타임 기본값Runtime Defaults

기본적으로 통합 API는 SGen 가비지 수집기 및 새 참조 횟수 개체 소유권을 추적 하기 위한 시스템입니다.The Unified API by default uses the SGen garbage collector and the New Reference Counting system for tracking object ownership. Xamarin.Mac로 동일한 기능으로 이식 되었습니다.This same feature has been ported to Xamarin.Mac.

많은 개발자가 이전 시스템을 사용 하 여 직면 한도 쉽게 수행할 수 있는 문제를 해결할 메모리 관리합니다.This solves a number of problems that developers faced with the old system and also ease memory management.

새 Refcount 클래식 API에 대해서도 사용 하도록 설정할 수는 있지만 기본 보수적인 이며 사용자가 변경할 필요가 없습니다.Note that it is possible to enable New Refcount even for the Classic API, but the default is conservative and does not require users to make any changes. 통합 API를 사용 하 여 기본값을 변경 하는 기회를 하 고 동시에 개발자가 모든 향상 된 기능을 제공 합니다. 이러한 리팩터링 및 코드를 다시 테스트 합니다.With the Unified API, we took the opportunity of changing the default and give developers all the improvements at the same time that they refactor and re-test their code.

API 변경 내용API Changes

통합 API는 사용 되지 않는 메서드를 제거 하 고 몇 가지 인스턴스가 있습니다 클래식 Api의 원래 MonoTouch 및 MonoMac 네임 스페이스에 바인딩된 경우 API 이름에 오타가 있었던 합니다.The Unified API removes deprecated methods and there are a few instances where there were typos in the API names when they were bound to the original MonoTouch and MonoMac namespaces in the Classic APIs. 이러한 인스턴스는 새 통합 Api에서 해결 되었습니다 하 고 구성 요소, iOS 및 Mac 응용 프로그램에서 업데이트 해야 합니다.These instances have been corrected in the new Unified APIs and will need to be updated in your component, iOS and Mac applications. 가장 일반적으로 발생할 수의 목록을 다음과 같습니다.Here is a list of the most common ones you might run into:

클래식 API 메서드 이름Classic API Method Name 통합 된 API 메서드 이름Unified API Method Name
UINavigationController.PushViewControllerAnimated() UINavigationController.PushViewController()
UINavigationController.PopViewControllerAnimated() UINavigationController.PopViewController()
CGContext.SetRGBFillColor() CGContext.SetFillColor()
NetworkReachability.SetCallback() NetworkReachability.SetNotification()
CGContext.SetShadowWithColor CGContext.SetShadow
UIView.StringSize UIKit.UIStringDrawing.StringSize

클래식에서 통합 API로 전환 하는 경우 변경의 전체 목록을 참조 하세요. 당사의 클래식 (monotouch.dll) vs 통합 (Xamarin.iOS.dll) API 차이점 설명서.For a full list of changes when switching from the Classic to the Unified API, please see our Classic (monotouch.dll) vs Unified (Xamarin.iOS.dll) API differences documentation.

업데이트에 통합Updating to Unified

이전/분류/사용 되지 않는 몇 가지 API 클래식 에서 사용할 수 없는 합니다 통합 API.Several old/broken/deprecated API in classic are not available in the Unified API. 해결 하기가 수는 CS0616 경고 프로그램 (수동 또는 자동)를 시작 하기 전에 업그레이드 해야 하므로 [Obsolete] 오른쪽 api 안내 메시지 (경고의 일부) 특성입니다.It can be easier to fix the CS0616 warnings before starting your (manual or automated) upgrade since you'll have the [Obsolete] attribute message (part of the warning) to guide you to the right API.

게시 하는 것에 diff 클래식 vs 통합 프로젝트 업데이트 전후 사용할 수 있는 API 변경 내용입니다.Note that we are publishing a diff of the classic vs unified API changes that can be used either before or after your project updates. 여전히 수정는 클래식 됩니다에 대 한 호출을 자주 obsoletes 하 여 (작은 문서 조회) 시간을 절약할 수 있습니다.Still fixing the obsoletes calls in Classic will often be a time saver (less documentation lookups).

다음이 지침에 따라 기존 iOS 앱을 업데이트, 또는 Mac 앱 통합 API로 합니다.Follow these instructions to update existing iOS apps, or Mac apps to the Unified API. 이 페이지의 나머지 부분을 검토 하 고 이러한 팁 코드 마이그레이션하는 방법에 대 한 자세한 내용은 합니다.Review the remainder of this page, and these tips for additional information on migrating your code.


이전에 클래식 API를 통해 Xamarin.iOS 지원 되는 NuGet 패키지를 사용 하 여 해당 어셈블리를 게시 합니다 Monotouch10 플랫폼 모니커입니다.NuGet packages that previously supported Xamarin.iOS via the Classic API published their assemblies using the Monotouch10 platform moniker.

Unified API 소개-호환 패키지에 대 한 새 플랫폼 식별자 Xamarin.iOS10합니다.The Unified API introduces a new platform identifier for compatible packages - Xamarin.iOS10. 기존 NuGet 패키지를 Unified API에 대해 구성 하 여이 플랫폼에 대 한 지원을 추가 하도록 업데이트 해야 합니다.Existing NuGet packages will need to be updated to add support for this platform, by building against the Unified API.


폼에 오류가 있는 경우 "오류 3 동일한 Xamarin.iOS 프로젝트에서 'monotouch.dll' 및 'Xamarin.iOS.dll'를 포함할 수 없습니다-'Xamarin.iOS.dll'는 'monotouch.dll'에서 참조 하는 동안 명시적으로 참조 됩니다 ' xxx, 버전 = 0.0.000, Culture = neutral, PublicKeyToken = null'" Unified Api로 응용 프로그램으로 변환 후 일반적으로 통합 API로 업데이트 되지 않은 프로젝트에서 구성 요소 또는 NuGet 패키지 사용 하지 때문입니다.If you have an error in the form "Error 3 Cannot include both 'monotouch.dll' and 'Xamarin.iOS.dll' in the same Xamarin.iOS project - 'Xamarin.iOS.dll' is referenced explicitly, while 'monotouch.dll' is referenced by 'xxx, Version=0.0.000, Culture=neutral, PublicKeyToken=null'" after converting your application to the Unified APIs, it is typically due to having either a component or NuGet Package in the project that has not been updated to the Unified API. 기존 구성 요소/NuGet을 제거 하 고, 통합 Api를 지 원하는 버전으로 업데이트 하 고, 클린 빌드를 수행 해야 합니다.You'll need to remove the existing component/NuGet, update to a version that supports the Unified APIs and do a clean build.

64 비트가는 길The Road to 64 Bits

32 비트 및 64 비트 응용 프로그램 및 프레임 워크에 대 한 정보를 지원 하기 위해 백그라운드에 대 한 참조를 32 및 64 비트 플랫폼 고려 사항합니다.For background on supporting 32 and 64 bit applications and information about frameworks see the 32 and 64 bit Platform Considerations.

새 데이터 형식New Data Types

차이의 핵심인 Mac 및 iOS Api 모두는 항상 32 비트에서 32 비트 플랫폼 및 64 비트 플랫폼에서 64 비트는 아키텍처 관련 데이터 형식을 사용 합니다.At the core of the difference, both Mac and iOS APIs use an architecture-specific data types that are always 32 bit on 32 bit platforms and 64 bit on 64 bit platforms.

예를 들어, Objective-c로 매핑하는 NSInteger 데이터 형식을 int32_t 32 비트 시스템 및 int64_t 64 비트 시스템에서.For example, Objective-C maps the NSInteger data type to int32_t on 32 bit systems and to int64_t on 64 bit systems.

통합 API에서이 동작은 일치를 교체 하는 이전을 사용 하는 int (항상으로 정의 되는.NET System.Int32)을 새 데이터 형식: System.nint합니다.To match this behavior, on our Unified API, we are replacing the previous uses of int (which in .NET is defined as always being System.Int32) to a new data type: System.nint. 있습니다 생각할 수 있습니다 "n" 의미 "네이티브" 플랫폼의 기본 정수를 입력 합니다.You can think of the "n" as meaning "native", so the native integer type of the platform.

도입한 nint, nuintnfloat 필요한 경우 이러한 기반으로 구축 된 데이터 형식으로 제공 합니다.We are introducing nint, nuint and nfloat as well providing data types built on top of them where necessary.

이러한 데이터 형식 변경에 대 한 자세한 내용은 참조는 네이티브 형식을 문서.To learn more about these data type changes, see the Native Types document.

IOS 앱의 아키텍처를 검색 하는 방법How to detect the architecture of iOS apps

응용 프로그램을 32 비트 또는 64 비트 iOS 시스템에서 실행 되 고 있는지 알고 해야 하는 경우가 있을 수 있습니다.There might be situations where your application needs to know if it is running on a 32 bit or a 64 bit iOS system. 아키텍처를 확인 하려면 다음 코드를 사용할 수 있습니다.The following code can be used to check the architecture:

if (IntPtr.Size == 4) {
    Console.WriteLine ("32-bit App");
} else if (IntPtr.Size == 8) {
    Console.WriteLine ("64-bit App");

배열 및 System.Collections.GenericArrays and System.Collections.Generic

때문에 C# 인덱서의 형식을 예상 int를 명시적으로 캐스팅 해야 nint 값을 int 컬렉션이 나 배열의 요소에 액세스 하려면.Because C# indexers expect a type of int, you'll have to explicitly cast nint values to int to access the elements in a collection or array. 예를 들어:For example:

public List<string> Names = new List<string>();

public string GetName(nint index) {
    return Names[(int)index];

왜냐하면 예상된 동작에서 캐스팅 intnint 는 64 비트에서 손실, 암시적 변환이 수행 되지 않습니다.This is expected behavior, because the cast from int to nint is lossy on 64 bit, an implicit conversion is not done.

NSDate 날짜/시간 변환Converting DateTime to NSDate

암시적으로 변환 된 통합 Api를 사용 하는 경우 DateTimeNSDate 값 이상으로 수행 됩니다.When using the Unified APIs, the implicit conversion of DateTime to NSDate values is no longer performed. 이러한 값을 명시적으로 다른 형식 간에 변환 될 해야 합니다.These values will need to be explicitly converted from one type to another. 이 프로세스를 자동화 하려면 다음 확장 메서드를 사용할 수 있습니다.The following extension methods can be used to automate this process:

public static DateTime NSDateToDateTime(this NSDate date)
    // NSDate has a wider range than DateTime, so clip
    // the converted date to DateTime.Min|MaxValue.
    double secs = date.SecondsSinceReferenceDate;
    if (secs < -63113904000)
        return DateTime.MinValue;
    if (secs > 252423993599)
        return DateTime.MaxValue;
    return (DateTime) date;

public static NSDate DateTimeToNSDate(this DateTime date)
    if (date.Kind == DateTimeKind.Unspecified)
        date = DateTime.SpecifyKind (date, /* DateTimeKind.Local or DateTimeKind.Utc, this depends on each app */)
    return (NSDate) date;

사용 되지 않는 Api 및 오타Deprecated APIs and Typos

내부 Xamarin.iOS 클래식 (monotouch.dll) API는 [Obsolete] 특성을 두 가지 방법으로 사용 했습니다.Inside Xamarin.iOS classic API (monotouch.dll) the [Obsolete] attribute was used in two different ways:

  • 사용 되지 않는 iOS API: 이 경우 Apple 힌트를 최신 버전으로 대체 되는 때문에 API를 사용 하 여 중지할 수 있습니다.Deprecated iOS API: This is when Apple hints to you to stop using an API because it's being superseded by a newer one. 클래식 API 이것도 이며 종종 필요 (iOS의 이전 버전 지원) 하는 경우.The Classic API is still fine and often required (if you support the older version of iOS). 이러한 API (및 [Obsolete] 특성) 새 Xamarin.iOS 어셈블리에 포함 되어 있습니다.Such API (and the [Obsolete] attribute) are included into the new Xamarin.iOS assemblies.
  • 잘못 된 API 일부 API 이름에 오타를 했습니다.Incorrect API Some API had typos on their names.

호환성을 위해 사용할 수 있는 기존 코드를 유지 하면서 원래 어셈블리 (monotouch.dll 및 XamMac.dll)에 대 한 하지만 Xamarin.iOS.dll과 Xamarin.Mac 통합 API 어셈블리에서 제거한For the original assemblies (monotouch.dll and XamMac.dll) we kept the old code available for compatibility but they have been removed from the Unified API assemblies (Xamarin.iOS.dll and Xamarin.Mac)

NSObject 서브 클래스.ctor(IntPtr)NSObject subclasses .ctor(IntPtr)

모든 NSObject 서브 클래스에 허용 하는 생성자는 IntPtr합니다.Every NSObject subclass has a constructor that accepts an IntPtr. 이것이 어떻게 네이티브 ObjC 핸들에서 새 관리 되는 인스턴스를 인스턴스화할 수 것입니다.This is how we can instantiate a new managed instance from a native ObjC handle.

이것이 클래식에서을 public 생성자입니다.In classic this was a public constructor. 하지만이 사용자 코드에서이 기능을 오용 하기는 몇 가지를 만드는 예를 들어 관리 되는 인스턴스 단일 ObjC 인스턴스 또는 는 관리 되는 인스턴스 만들기 (하위 클래스)에 대 한 예상 되는 관리 되는 상태 부족 합니다.However it was easy to misuse this feature in user code, e.g. creating several managed instances for a single ObjC instance or creating a managed instance that would lack the expected managed state (for subclasses).

이러한 유형의 문제를 방지 하려면 합니다 IntPtr 생성자는 이제 protected통합 하위 클래스에 대해서만 사용할 수 있도록 API.To avoid those kind of problems the IntPtr constructors are now protected in unified API, to be used only for subclassing. 그러면 수정/safe API 즉, 핸들에서 관리 되는 인스턴스를 만드는 데 사용 됩니다.This will ensure the correct/safe API is used to create managed instance from handles, i.e.

var label = Runtime.GetNSObject<UILabel> (handle);

이 API (이미 있는 경우) 기존 관리 되는 인스턴스를 반환 합니다 (필수) 하는 경우 새로 만듭니다.This API will return an existing managed instance (if it already exists) or will create a new one (when required). 클래식 및 통합 된 API에서 사용할 수 있는 이미입니다.It is already available in both classic and unified API.

유의 합니다 .ctor(NSObjectFlag) 이기도 protected 하는데이 하위 클래스 외부에서 거의 사용 했습니다.Note that the .ctor(NSObjectFlag) is now also protected but this one was rarely used outside of subclassing.

작업을 사용 하 여 대체 NSActionNSAction Replaced with Action

Unified Api를 통해 NSAction 표준.NET 위해 제거 되었습니다 Action합니다.With the Unified APIs, NSAction has been removed in favor of the standard .NET Action. 이 중대 한 개선 사항은 때문 Action 반면 공용.NET 형식에는 NSAction xamarin.ios 것 이었습니다.This is a big improvement because Action is a common .NET type, whereas NSAction was specific to Xamarin.iOS. 정확히 동일한 작업을 모두 수행 없지만 distinct 및 호환 되지 않는 형식 같은 결과 쓸 수 있도록 더 많은 코드에서 발생 합니다.They both do exactly the same thing, but they were distinct and incompatible types and resulted in more code having to be written to achieve the same result.

예를 들어 다음과 같이 기존 Xamarin 응용 프로그램에 다음 코드가 포함 되어 있습니다.For example, if your existing Xamarin application included the following code:

UITapGestureRecognizer singleTap = new UITapGestureRecognizer (new NSAction (delegate() {
    ShowDropDownAnimated (tblDataView);

이제 간단한 람다를 사용 하 여 교체할 수 있습니다.It can now be replaced with a simple lambda:

UITapGestureRecognizer singleTap = new UITapGestureRecognizer (() => ShowDropDownAnimated(tblDataView));

이전 되는 컴파일러 오류 때문에 Action 할당할 수 없습니다 NSAction, 있지만 UITapGestureRecognizer 이제는 Action 대신는 NSAction Unified Api에서 유효 합니다.Previously that would be a compiler error because an Action can't be assigned to NSAction, but since UITapGestureRecognizer now takes an Action instead of an NSAction it is valid in the Unified APIs.

작업으로 교체 하는 사용자 지정 대리자Custom delegates replaced with Action

통합 (예: 하나의 매개 변수) 간단한.net의 대리자 대체 됨 Action<T>합니다.In unified some simple (e.g. one parameter) .net delegates were replaced with Action<T>. 예:E.g.

public delegate void NSNotificationHandler (NSNotification notification);

이제 사용할 수는 Action<NSNotification>합니다.can now be used as an Action<NSNotification>. 이 승격 코드 다시 사용 하 고 Xamarin.iOS 응용 프로그램과 사용자 고유의 응용 프로그램 내에서 코드 중복을 줄입니다.This promote code reuse and reduce code duplication inside both Xamarin.iOS and your own applications.

작업 < 부울, NSError >> 태스크로 대체Task replaced with Task<Boolean,NSError>>

클래식 있었습니다 일부 비동기 Api 반환 Task<bool>합니다.In classic there were some async APIs returning Task<bool>. 하지만 일부 그 중 여기서 사용 하는 NSError 서명의 즉 속해를 bool 이미 true 가져오려는 예외를 catch 해야 하 고는 NSError.However some of them where are to use when an NSError was part of the signature, i.e. the bool was already true and you had to catch an exception to get the NSError.

이 패턴에서 변경 된 일부 오류는 매우 일반적 이므로 반환 값에 유용 하지 않아서 통합 반환할는 Task<Tuple<Boolean,NSError>>합니다.Since some errors are very common and the return value was not useful this pattern was changed in unified to return a Task<Tuple<Boolean,NSError>>. 따라서 성공 및 비동기 호출 하는 동안 발생 했을 수 있는 모든 오류를 모두 확인할 수 있습니다.This allows you to check both the success and any error that could have happened during the async call.

NSString vs 문자열NSString vs string

경우에 따라에서 일부 상수에서 변경 해야 stringNSStringUITableViewCellIn a few cases some constants had to be changed from string to NSString, e.g. UITableViewCell


public virtual string ReuseIdentifier { get; }


public virtual NSString ReuseIdentifier { get; }

.NET 좋습니다 일반적 System.String 형식입니다.In general we prefer the .NET System.String type. 그러나 일부 네이티브 API는 상수 포인터 (하지 자체 문자열)을 비교 하는 데 Apple 지침에도 불구 하 고 있으며으로 상수를 노출 하는 경우만 작동할 수 있습니다 NSString합니다.However, despite Apple guidelines, some native API are comparing constant pointers (not the string itself) and this can only work when we expose the constants as NSString.

Objective-c 프로토콜Objective-C Protocols

원래 MonoTouch 전체 지원 ObjC 프로토콜에 대 한 일부 최적이 아닌 없는, API의 가장 일반적인 시나리오를 지원 하기 위해 추가 되었습니다.The original MonoTouch did not have full support for ObjC protocols and some, non-optimal, API were added to support the most common scenario. 이 제한은 더 이상 존재 하지 않습니다 하지만 여러 Api 유지는 이전 버전과 호환성을 위해 내부 monotouch.dllXamMac.dll입니다.This limitation does not exists anymore but, for backward compatibility, several APIs are kept around inside monotouch.dll and XamMac.dll.

이러한 제한 사항은 제거 되 고 Unified Api에서 정리 합니다.These limitations have been removed and cleaned up on the Unified APIs. 대부분의 변경 내용을 다음과 같이 표시 됩니다.Most changes will look like this:


public virtual AVAssetResourceLoaderDelegate Delegate { get; }


public virtual IAVAssetResourceLoaderDelegate Delegate { get; }

합니다 I 수단을 접두사 통합 ObjC 프로토콜에 대 한 특정 형식 대신 인터페이스를 노출 합니다.The I prefix means unified expose an interface, instead of a specific type, for the ObjC protocol. 이 원하지 않는 하위 Xamarin.iOS에서 제공 되는 특정 형식의 경우 완화 됩니다.This will ease cases where you do not want to subclass the specific type that Xamarin.iOS provided.

또한 허용 되는 일부 API를 더욱 정확 하 고 사용 하기 쉬운 예를 들어 다음과 같습니다.It also allowed some API to be more precise and easy to use, e.g.:


public virtual void SelectionDidChange (NSObject uiTextInput);


public virtual void SelectionDidChange (IUITextInput uiTextInput);

이러한 API 설명서를 참조 하지 않고 쉽게 우리에 게 이제 되며 IDE 코드 완료 프로토콜/인터페이스를 기반으로 하는 유용한 제안과 함께 제공 됩니다.Such API are now easier to us, without referring to documentation, and your IDE code completion will provide you with more useful suggestions based on the protocol/interface.

NSCoding 프로토콜NSCoding Protocol

우리의 원래 바인딩을 지원 하지 않는 경우에는.ctor(NSCoder)-모든 형식에 대 한 포함 된 NSCoding 프로토콜입니다.Our original binding included an .ctor(NSCoder) for every type - even if it did not support the NSCoding protocol. 단일 Encode(NSCoder) 에 표시 된 메서드는 NSObject 개체를 인코딩할 합니다.A single Encode(NSCoder) method was present in the NSObject to encode the object. 하지만이 메서드는 인스턴스 NSCoding 프로토콜을 따르도록 하는 경우에 작동 합니다.But this method would only work if the instance conformed to NSCoding protocol.

Unified API에서이 수정 했습니다.On the Unified API we have fixed this. 새 어셈블리는 하나만 합니다 .ctor(NSCoder) 형식을 준수 하는 경우 NSCoding합니다.The new assemblies will only have the .ctor(NSCoder) if the type conforms to NSCoding. 또한 이러한 형식을 이제는 Encode(NSCoder) 준수 하는 메서드는 INSCoding 인터페이스입니다.Also such types now have an Encode(NSCoder) method which conforms to the INSCoding interface.

낮은 영향: 대부분의 경우에서이 변경으로 이전, 제거, 생성자를 사용할 수 없는 응용 프로그램 적용 되지 않습니다.Low Impact: In most cases this change won’t affect applications as the old, removed, constructors could not be used.

추가 팁Further Tips

알아야 할 추가 변경 내용은에 나와 합니다 통합 API로 앱을 업데이트 하기 위한 팁합니다.Additional changes to be aware of are listed in the tips for updating apps to the Unified API.

샘플 코드Sample Code

년 7 월 31 일을 기준으로이 새 API로 iOS 샘플의 포트에 게시 한 것은 magic-types 에서 분기 monotouch 샘플합니다.As of July 31st, we have published ports of the iOS samples to this new API on the magic-types branch at monotouch-samples.

Mac 용 둘 다에서 샘플을 확인 합니다 mac 샘플 magic 형식 분기에서 32/64 비트 샘플 뿐만 아니라 (Mavericks/Yosemite에서 새 Api를 표시) 리포지토리 mac 샘플합니다.For Mac, we are checking samples in both the mac-samples repo (showing new APIs in Mavericks/Yosemite) as well as 32/64 bit samples in the magic-types branch mac-samples.