Search code, repositories, users, issues, pull requests...

xcframework are a new format of frameworks which allow multiple platforms to live side by side.

We should teach binding projects (XI and XM) to accept xcframework bundles.

In addition, we need to research how we can leverage this:

Packaging some of our libraries our outputs?
Embeddinator output (if so, file issue with details and move on)

mentioned this

on Jun 10, 2019

[Meta] Xcode 11 Support #6206

changed the title ~~[-][xcode11-feature] xcframework support[/-]~~ [xcode11-support] xcframework support

on Jun 10, 2019

added this to the xcode11 milestone

self-assigned this

added

mentioned this

Example for binding compiled swift library xamarin/binding-tools-for-swift#199

awattar

Hi. Any ETA for this enhancement?

ContributorAuthor

Thanks for the interest @awattar - In general we don't have ETA for enhancements. Either they are in work or our backlog.

Right now the teams is focused on Xcode 12 and the port to .NET 6, so it may be some time before we pick this up.

awattar

Thanks @chamons. It started to be a problem because apps referencing dynamic frameworks cannot be distributed to AppStore due to unsupported architecture - x86_64 so most of them were switched to modern xcframeworks that are currently unsupported by the Xamarin.iOS bindings/apps. Workarounds require special IPA handling or creating cumbersome configurations for simulator/device.

It is not something new but over a year old enhancement that could be put somewhere in the schedule for the sake of loyal developers and their customers ;)

nrbrook

@awattar @chamons It is possible to strip non-iOS architectures out of dynamic frameworks during build using a script such as Realm's for submitting to App Store. For frameworks that have switched to XCFramework, the relevant frameworks could be pulled out of the XCFramework and merged as required.

However, another problem is approaching with Apple Silicon. Xcode 12 builds simulator binaries for x86_64, i386, and now arm64 by default, for running in simulator on Apple Silicon. If attempting to make a fat binary, the arm64 simulator slice conflicts with the iOS arm64 slice. The arm64 simulator slice can be removed with lipo, but this means that the framework can't run in simulator on Apple Silicon. As such, I have to distribute a fat binary which doesn't support Apple Silicon for Xamarin. This means that until XCFrameworks are supported, many Xamarin projects using binary libraries and frameworks will not run in the simulator on Apple Silicon.

rolfbjarne

mentioned this

on Sep 7, 2020

[xcode12] macOS on Apple Silicon #8934

rolfbjarne

Member

@nrbrook that's a very good point, and we'll have it in mind when we're adding simulator support on Apple Silicon

tonyarnold

We've just hit this with Reveal's SDK - we're in a tight spot here: we can't really afford not to support Apple Silicon in our framework, but this necessitates shipping as an XCFramework so that there's no overlapping slices.

Is there an ETA on support for Xamarin consuming XCFrameworks?

ContributorAuthor

It's in work - #10046

removed this from the xcode11 milestone

on Dec 1, 2020

15 remaining items

Contributor

Preview compiled the binding project fine, however, the actual app's linking process failed. (Thus the workaround).

This is basically what we're doing. The msbuild task is resolving the correct .framework path inside the .xcframework based on the OS and architecture. The rest of the build (e.g. mtouch and native compiler/linker) are unaware of XCFrameworks.

Contributor

Closing: d16-9 (XI 14.14) was released to stable

closed this as completed

on Mar 2, 2021

4brunu

Does this means that now Xamarin fully supports XCFrameworks?

There are still a few issues with this it seems.
On Visual Studio for Mac (using Xamarin.iOS 14.14.2.5) I can build a binding project with a xcframework native reference fine and judging by the resulting DLL size and content the xcframework is included within it.

However when I use said DLL (or direct project reference) in a Xamarin.iOS app an issue occurs.
While the C# classes part of the binding are available it seems the framework (derived from the embedded xcframework) is not included in the app build, even though it is included in the dll. This leads to the same MT5211 errors mentioned earlier.
The only way I can make the binding project/dll work is explicitly include the xcframework in the Xamarin.iOS app itself as a native reference.

For binding projects with references to static libraries (.a) or non-xc frameworks it still works as expected (.a and .framework embedded in the binding are included in the build).

I've added a test project showing this issue (using the Universal framework that was supplied as a test xcframework):
BindingTest.zip

4brunu

Is there any issue where we I can follow this problem?

I've created a new issue for the binding project issue specifically: #10774

https://github.com/xamarin/xamarin-macios/blob/5ef69f173bcab367117f031bc4faa48dfec3e42c/msbuild/Xamarin.MacDev.Tasks.Core/Tasks/ResolveFrameworksBase.cs#L149-L163

There is also a Windows exclusive bug regarding xcframeworks.
Whenever a Xamarin.iOS app references a xcframework (and builds fine on mac) the build process produced the following error on Windows (connected to a Mac build server):

C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Xamarin\iOS\Xamarin.Shared.targets(142,3): error : Universal.xcframework has an incorrect or unknown format and cannot be processed.

Building a binding project on Windows doesn't generate the above error, but the resulting DLL is missing the expected embedded xcframework. This also doesn't happen on Mac.

The above error seems to be error E0174 which can only be found in the code block below, but I haven't been able to figure out why it happens/why it only happens on Windows builds.

@leonluc-dev : do you have any update?
Does Xamarin fully supports XCFrameworks now?
I tried to create our sdk for Xamarin but it seems hard for us to understand how to create binding project with XCFrameworks.
All tutorial documents are also not updated for XCFramework.

@nguyenhuutinh I don't know the exact details (I'm not part of the Xamarin team). But Xamarin does support XCFrameworks on Mac, although with a few quirks to keep in mind. On Windows it's still broken (as of April 23, 2021 using Visual Studio 16.9.4).

Windows

Binding projects using XCFrameworks cannot be properly built on Windows (your resulting binaries and resources will be incomplete).
~~Any Xamarin.iOS apps referencing a XCframework based binding projects will not build on Windows (the compiler will show linker errors)~~ (This was fixed in Visual Studio 16.10)

Mac

On Mac using XCFrameworks in Xamarin binding projects works, but there are a few things to keep in mind:

You add the XCFramework to the binding project as a native reference just like you would a regular framework or static library.
There is currently a bug in Visual Studio for Mac which causes any XCFramework native reference to be marked as a static library after they are added to the project. You need to manually change this flag back to Framework.

<NativeReference Include="MyFramework.xcframework">
    <Kind>Static</Kind>
    <SmartLink>False</SmartLink>
</NativeReference>

to 

<NativeReference Include="MyFramework.xcframework">
    <Kind>Framework</Kind>
    <SmartLink>False</SmartLink>
</NativeReference>

Any binding project using XCFramework requires the NoBindingEmbedding value to be set on the project file. As of now, Visual Studio for Mac doesn't do this for you, so you have to set this value manually.

<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
     <!--Other properties omitted for brevity-->
     <PropertyGroup>
        <NoBindingEmbedding>true</NoBindingEmbedding>
    </PropertyGroup>
</Project>

ApiDefinition.cs and Structs.cs files are written the same way as with static libraries and regular frameworks
After building the binding project the output folder will contain a dll file and a .resources folder. You need both the dll file and the resources folder to use the binding in a Xamarin.iOS app.
If you add the binding to a Xamarin.iOS app as a project reference the .resources folder will be handled automatically.
If you reference the resulting dll directly make sure the .resources folder is in the same location as the dll for it to work (you don't need to explictly reference the .resources folder. It being in the same folder as the dll is enough.)

NOTE: As for now Objective Sharpie, a tool to automatically generate ApiDefinition.cs files, cannot handle XCFrameworks yet. So you have to write the definition files manually or generate the files from a regular framework version of the library you want to bind and reuse them were possible.

Hopefully most of the bugs on Windows and in Visual Studio for Mac get ironed out soon. But this should at least get you a working XCFramework binding on Mac.

@leonluc-dev thanks for your detail information.
Yes, I got problem when using Objective Sharpie to generate metadata from XCFramework.
let me try to do it manually.

Thank you

hi @leonluc-dev , thanks, I tried with your suggestion. I can compile now.
But I got this error due to new instance of my class in framework.
var test = new CoverService(); in ViewDidLoad()

Could not create an native instance of the type 'Library.CoverService': the native class hasn't been loaded.

seems that Xamarin didnot load my xcframework correctly.
have you experienced on this or any suggestion how to debug this issue?

Thanks

@nguyenhuutinh I'm not sure. The most common causes I've seen for that error are:

An incomplete/faulty ApiDefinitions.cs specification
The binding project is missing a required Objective-C compiler flag for the framework (like the "-ObjC" flag or a framework dependency).
The (xc)framework is missing support for the device architecture you are trying to run the app on. (You can check which architectures it supports by the folder names inside the xcframework's root)

In a lot of these cases the binding project might still compile but will give runtime errors when used in an app.