Forum Xamarin.iOS

Supporting the Unified APIs and 64 Bit Apps

KMullinsKMullins USMember, Xamarin Team Xamurai
edited May 2015 in Xamarin.iOS


As you might be aware, Apple will be requiring that all new iOS app submission support 64 bits by February 15, 2015. As a result all Xamarin Applications, Components and Binding Library Projects must be converted to the new Unified APIs.

Xamarin has created quite a bit of documentation on the new Unified APIs and what is required to support 64 bit applications in Xamarin.iOS or Xamarin.Mac.

For those working with Xamarin.iOS or Xamarin.Mac projects and for more information about the Unified APIs:

For those working with reusable component projects, all of our component documentation has been updated:

  • Migrating to Unified API for Components - This article covers the steps required to update an existing Xamarin component to support the Unified APIs for Xamarin.IOS and Xamarin.Mac applications.
  • Component Store Submission - Quickstart - This guide provides a quick and simple guide to help you to build, bundle and submit your components to the Xamarin Component Store.
  • Component Store Submission Guidelines - This document gives you an in depth look at the process of creating a component and provides all the information needed to build, bundle and submit your components to the Xamarin Component store.
  • Component Store Review Guidelines - This document provides the rules and requirements that your component should comply with to ensure it is reviewed and approved as quickly as possible.

For those working with the binding projects for 3rd party Objective-C Libraries. All of our binding documents have been updated to support Unified APIs and 64 bit apps:

  • Binding Objective-C Libraries - This document describes the process used to create C# bindings of Objective-C APIs and how the idioms in Objective-C are mapped to the idioms used in .NET.If you are binding just C APIs, you should use the standard .NET mechanism for this, the P/Invoke framework.
  • Binding Definition Reference Guide - This is the reference guide that describes all of the attributes available to binding authors to drive the binding generation process.
  • Binding Details - This document contains some of the internals of how a binding takes place. It is an advanced document with some technical information.

Finally, we have a document that covers migrating a Binding Project to the Unified APIs that should be released soon. It is in the review process right now. I'll post a link here when it is released.

If anyone has a question about supporting the Unified APIs, please let me know.





  • KMullinsKMullins USMember, Xamarin Team Xamurai

    For anyone interested in updating a Binding Project, the Migrating a Binding to the Unified API doc just went live.

  • XamarinIsTheBestXamarinIsTheBest USMember
    edited November 2014

    I'm trying to bind an existing binding project to the Unified API but I have difficulties if I use the Xamarin Studio Binding Project Template.

    According to Migrating a Binding to the Unified API

    If we are using a Xamarin Studio Binding Project Template to build our API, we'll need to update to the new Unified API version of the Binding Project Template. The easiest way to do this is to start a new Unified API Binding Project and copy over all of the existing code and settings.

    So I created a new Xamarin Binding Project using iOS > Unified API > iOS Binding Project.
    Then, I added my .a file and build. And I get an error.

    Error: /Users/XamarinIsTheBest/Projects/UnifiedDropbox/UnifiedDropbox/UnifiedDropbox.csproj: /Users/XamarinIsTheBest/Projects/UnifiedDropbox/UnifiedDropbox/UnifiedDropbox.csproj could not import "$(MSBuildExtensionsPath)\Xamarin\iOS\Xamarin.iOS.ObjCBinding.CSharp.targets" (UnifiedDropbox)

    So to fix this problem, I changed the Import element in the .csproj from:

    <Import Project="$(MSBuildExtensionsPath)\Xamarin\iOS\Xamarin.iOS.ObjCBinding.CSharp.targets" />


    <Import Project="$(MSBuildExtensionsPath)\Xamarin\Xamarin.ObjcBinding.CSharp.targets" />

    And I also added a new TargetFrameworkIdentifier element in the PropertyGroup element


    These two fixes seem to fix my error but it feels entirely hack-ish to me. Is this the correct way to ensure that my bindings project is bounded with the Unified API?


    I am using Xamarin Studio Version 5.5.4 (build 13)
    Xamarin.iOS Version: (Enterprise Edition)

  • KMullinsKMullins USMember, Xamarin Team Xamurai

    Hi @XamarinIsTheBest‌,

    Looks like you have found a bug, both of your fixes should already be part of the Unified Binding template so I'm filing a bug report on this and it should be fixed in the next release.

    To answer your question, yes this will ensure that you are bound to the Unified APIs and those should already be in the template.

    Please let me know if you have any other questions.



  • kwlkwl USInsider, Developer Group Leader ✭✭

    I wrote a blog post on Unified API for iOS for those interested:

  • KMullinsKMullins USMember, Xamarin Team Xamurai

    Hi @kwl,

    Thanks for sharing the link to the post, good work.

    I've updated the Unified API docs to include the other cases that you found.

    Please let me know if you run into anything else and I'll include it in the docs as well.

    Thanks Again,


  • kwlkwl USInsider, Developer Group Leader ✭✭

    PushViewControllerAnimated() is also affected... :-)

  • KMullinsKMullins USMember, Xamarin Team Xamurai

    Thanks... Got it added too!

  • GerryHighGerryHigh USBeta ✭✭✭

    So, after porting my project to use the Unified API and fixing a bunch of errors I now get this error that I can't seem to find anything on it:
    Target _DetectSigningIdentity:
    /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS/Xamarin.iOS.Common.targets: error : Error executing task DetectSigningIdentityTask: Required property 'AppManifest' not set.
    Build FAILED.

    Anyone seen anything like this? I'm running on the Stable channel.


  • JustinDuffJustinDuff AUMember ✭✭

    Hi guys,

    Before I undertake this process of using the unified API, I currently have a 32 bit machine with Windows 8 on it that I use to build Xamarin projects. The Macbook with the build server is Yosemite (as of yesterday) and XCode 6.1.1. Will I need a 64bit windows machine to compile the code? It might be a silly question, but I need to know before I start the migration project, as if I need a new PC, it will take over a day to rebuild it with VS, xamarin etc :(

  • kwlkwl USInsider, Developer Group Leader ✭✭

    I haven't tried on 32-bit Windows but I don't see how that could have an impact. I'd say it works.

  • RolfBjarneKvingeRolfBjarneKvinge USXamarin Team Xamurai

    You do not need a 64-bit Windows do create 64-bit iOS apps.

  • tdadonetdadone BRMember


    I've migrated my Classic API project to Unified API and have resolved all the issues but one.

    "Failed to resolve "System.DateTime Foundation.NSDate::op_Implicit(Foundation.NSDate)" reference from "Xamarin.iOS, Version=, Culture=neutral, PublicKeyToken=84e04ff9cfb79065" C:\Program Files (x86)\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets"

    There are others experiencing this issue as well:

    I'm using the latest beta at the moment v.3.9.185.



  • JustinDuffJustinDuff AUMember ✭✭

    Hi @RolfLangenberg‌ , OK great. That's a relief!

  • RolfBjarneKvingeRolfBjarneKvinge USXamarin Team Xamurai

    @tdadone: you're using a component which hasn't been updated to the final API in Xamarin.iOS 8.6 (the component is using a method that doesn't exist anymore).

    For the moment all you can do is wait until the component is updated.

  • tdadonetdadone BRMember

    @RolfBjarneKvinge‌ thanks for the info. I've narrowed down the libraries used by the application and it appears to be that the cause of error is Xamarin.Mobile. I've updated to the latest version of the component which supposedly works with the Unified API but when instantiating a MediaPicker the DateTime-NSDate error shows up.

  • kwlkwl USInsider, Developer Group Leader ✭✭

    Yes, there was a breaking change for the implicit DateTime-NSDate conversion in Unified API with Xamarin.iOS 8.6. You might want to switch back to an older version (e.g., switch to stable channel).

  • I'm getting this:

    MTOUCHTASK: error MT2002: Failed to resolve "System.Void UIKit.UIWebView::set_Delegate(UIKit.UIWebViewDelegate)" reference from "Xamarin.iOS, Version=, Culture=neutral, PublicKeyToken=84e04ff9cfb79065"
    Task "MTouchTask" execution -- FAILED
    Done building target "_CompileToNative" in project "[[snip]].csproj".-- FAILED

    only when I compile in Release mode. Is there a place to look up what the unified equivalent would be?


  • I actually looked up the Unified API. It seems that Delegate should be there...

  • kwlkwl USInsider, Developer Group Leader ✭✭
  • GaborVargaGaborVarga HUMember ✭✭

    When trying to build my Xamarin Forms application with the Universal API am getting:

    Error MT2002: Failed to resolve
    "System.Void UIKit.UICollectionView::set_DataSource(UIKit.UICollectionViewDataSource)"
    reference from "Xamarin.iOS, Version=, Culture=neutral, PublicKeyToken=84e04ff9cfb79065" (MT2002)

    I understand that the type of this property was changed to IUICollectionViewDataSource, but how can I figure what component is setting this?

    I have the Xamarin.Forms package upgraded to

  • bradmbradm AUMember ✭✭✭

    Any word on if/when we could get Google Analytics updated to unified API?

  • Hello everyone. Will there also be a unified version of OpenTK? Casting all the nfloats to floats when using the Vector3 struct is a real pain.

  • PhilippLPhilippL USMember

    i just tried to build my app with unified API. Works well in simulator but not when deploying to device.

    MTOUCHTASK: error MT2002: Failed to resolve "System.Void CoreGraphics.CGBitmapContext::.ctor(System.IntPtr,System.Int32,System.Int32,System.Int32,System.Int32,CoreGraphics.CGColorSpace,CoreGraphics.CGImageAlphaInfo)" reference from "Xamarin.iOS, Version=, Culture=neutral, PublicKeyToken=84e04ff9cfb79065"

    Is it just possible that one of my libs (Monotouch.Dialog, xzing.ios) is not updated?

  • MihaMarkicMihaMarkic SI ✭✭✭✭

    Anybody having any luck with autofac? It doesn't work on unified api yelling he can't find a constructor.

  • MihaMarkicMihaMarkic SI ✭✭✭✭

    This is odd, this code returns no constructors on iPhone 5, while in simulator works fine:

    public class Tubo { }
    var type = typeof(Tubo);
    var cs = type.GetConstructors();
    // cs.Length == 0

    Sounds like a nasty bug to me.

  • MihaMarkicMihaMarkic SI ✭✭✭✭

    Mystery solved. Looks like Linker behaviour changed somewhere along the path (to Link all assemblies) of upgrading to Unified API and it was too aggressive.

  • MihaMarkicMihaMarkic SI ✭✭✭✭

    FYI Looks like the timeline for a stable Unified API release has been set to 5th January as per

  • RolfBjarneKvingeRolfBjarneKvinge USXamarin Team Xamurai

    @ArndvonOppenkowski‌: there already is a Unified version of OpenTK-1.0.dll, but have in mind that the native graphics API is using 32-bit floats even on a 64-bit CPU (not CGFloats), which means Vector3 will always use 32-bit floats.

  • bradmbradm AUMember ✭✭✭

    Timeline has been pushed back to mid-January.
    Is there anything crippling wrong with using what we have now to get it done? Have a bunch of apps for schools that were meant to go up late Dec but waited for unified API on Jan 5th which is now pushed back. Would be good just to use unified API that we have now and push all the builds out.

  • ChaseCarlileChaseCarlile USMember

    Where was it announced that the timeline has been pushed back? I guess I can stop clicking "Check for Updates" now.

  • bradmbradm AUMember ✭✭✭
    edited January 2015
  • For the record, for the time being, I was able to fix my problem by changing the linker settings to "don't link."

  • RolfBjarneKvingeRolfBjarneKvinge USXamarin Team Xamurai

    @BradMoore: if you're using the current Beta (and your app works fine), my suggestion would be to just release with it. There will be very few changes in final (Stable) release compared to the current Beta.

  • I hope I am missing something here and there is an easy solution to what might be a problem. I use Shared Projects a lot so the same source code is compiled on both Android and iOS. Therefore, if I make changes to all my ints to be nints in the shared code, will it compile under Android? Does Xamarin.Android know what nint is and can handle it? If not, doesn't the whole Unified API for iOS break Shared Projects? Similarly, I have been using RectangleF in my shared code because it is cross platform. If I change to CGRect, again Android won't understand it. This problem seems easier to resolve by continuing to use RectangleF in shared code and when it is used by iOS specific code, I can convert it to CGRect right then, maybe with an extension method or something.

  • rmaciasrmacias USBeta, University ✭✭✭✭✭

    ^ Good question. I'm in the same boat and about to head that route. In my planning, that is one question I had.

  • kwlkwl USInsider, Developer Group Leader ✭✭

    No, the n-types are only known by projects referencing Xamarin.iOS.dll. This is OK since your shared code should not contain any iOS or Android-specific code so there should be no need for you to use nint or nfloat in the shared projects. Only convert your values to n-types when calling the iOS API. It's OK to use RectangleF in the code shared between Android and iOS and convert to platform specific-types where applicable (though unusual). Do you actually pass a RectangleF to the Android API?

  • Thanks. Actually, I just checked, and no I do not pass a RectangleF into Android API, I convert to RectF first with an extension method. So the same thing will now happen on iOS, I would convert to CGRect with an extension method before passing into iOS unified API.

    Yes, leaving the shared code as int and casting to nint just before passing into iOS unified API should work too.

  • JimBennettJimBennett GBXamarin Team, Insider, University, Developer Group Leader ✭✭✭✭

    @ChaseCarlile‌ -

    So because updates don't require this, all new apps now have one less week with the stable channel for testing.

    Hopefully the end result will be less of an abortion than the iOS 8 mess.

  • BiswarupBiswarup USMember


    We have some existing Xamarin IOS apps which are using MonoTouch Foundation APIs. As per Apple's requirement, we now want to have a single binary for these apps with both 32-bit and 64-bit support.

    Is the only way to achieve this in Xamarin is to support Unified APIs ? We dont want to change code and change all MonoTouch APIs to Foundation APIs just to add 64 bit support.

    Any pointers?

    Thanks in advance

  • kwlkwl USInsider, Developer Group Leader ✭✭

    @Biswarup There is no other option. If you want to submit your app update after June 1, you have no choice.

Sign In or Register to comment.