[Prototype] Swift Code Extensions to Xamarin applications

[chamons]

Problem Context

As noted in multiple issues adding Swift support has been a recurring theme over the last few year's Xcode releases. The lack of direct support has lead customers to creating inventive solutions.

Despite the 'simple' problem statement: "Let us call Swift code from C#", this is actually a very difficult problem to solve for many reasons.

The three most intractable of these are:

• Swift APIs that are not marked with @objc can not be called with the traditional objc_msgSend nor p/invoke. The calling convention is actually not representable in C, as "self" must be passed in a a specific register by the calling conventions. In addition, Swift exceptions are stored in a register and thus not accessible either from C or p/invokes.
• The Swift type system is significantly different that the one in C#, with some types not expressible in C# without significant compile and run-time support,
• Swift uses an automatic reference counting (ARC) system for memory management that can be challenging for manual bindings to correctly interoperate with.

A full solution to this problem would require a tool such as Binding Tools for Swift to be complete, which still requires a significant amount of work.

However, there are many cases where a full API binding is not required, a "thin slice" written by hand will suffice.

Prototype

The prototype is a msbuild targets file that you can leverage to compile Swift into your application along with patterns needed to successfully call it.

1. Copy CompileSwift.targets next to your csproj
2. Add <Import Project="$(MSBuildThisFileDirectory)CompileSwift.targets" /> to the end of your csproj, but inside the final </Project> tag, like this
3. Create a file with a Swift extension and inside it define a free function you wish to invoke that takes as arguments and returns nothing or simple types such as integers:

public func ReloadWidgets ()  {
    WidgetCenter.shared.reloadAllTimelines() 
}

4. Decorate your functions with the @_cdecl attribute to declare that it should be invocable from C-like context, such as p/invoke:

@_cdecl("ReloadWidgets")
public func ReloadWidgets ()  {

5. Add one or more p/invokes in your C# project, that align with the Swift you wrote in step three:

    [DllImport ("__Internal", EntryPoint = "ReloadWidgets")]
    public extern static int ReloadWidgets ();

Be aware that your EntryPoint, the return value, and any arguments must match Swift exactly or undefined behavior will occur.

6. Call your p/invoke from C# code

7. Test things out and report back.

Known Limitations

• No support for linking in non-system Swift libraries
  So far all of the usages tests have been system Swift libraries. Likely this can be accomplished by adding linker flags:

            <_MainLinkerFlags Include="-L/usr/lib/swift" />

adding any swift static libraries:

            <_XamarinMainLibraries Include="@(SwiftObjectFiles)"/>

and copying in other libraries into your bundle build step extension.

• No IDE support - All of these steps must be done by hand, with a text editor
• No support for complex types, such as Strings, Structs, or Enums. Future partial support may be possible, but given the type system differences it will be limited at best.
• Manual creation of both sides of the interp bridge (Swift & C#).

Feedback

Development on this feature is in progress, and despite the limitations and required manual steps we feel that it may be useful for some use cases, specially for those who have been blocked and unable to progress on integration with some features, such as WidgetKit.

The team would appreciate any feedback on use of the prototype target, both successful and unsuccessful, and thoughts on what the most difficult steps were in testing it out.

[wjk]

Copy CompileSwift.targets next to your csproj

The link 404’s.

[chamons]

@wjk - Bah, those links were referencing my branch before landing in master. Fixed.

[motoko89]

@chamons Do you have any suggestion for debugging WidgetKit extension? Is it possible to do it from VS Mac with the actual host app installed?

[JeroenBer]

@chamons I wanted to test it on Xamarin.iOS but I got some errors, it only works for .NET6 iOS right ?

[rolfbjarne]

@JeroenBer yes, this is .NET 6 only

[chamons]

@motoko89 - Debugging is something on my radar to look into, but I doubt VSfM will have any support for a long time.

Your best bet, off the top of my head, would be somehow connecting to the App/Extension with Xcode and trying to set breakpoints on the swift there.

But as I noted before, I have not looked into this yet at all.

[Csaba8472]

I think, this is a viable solution for certain use cases like calling the widget update method and it's certainly easier than create a framework project and a binding project just to call one method.

However, if there is an initiative to create a way to use swift, I'd rather approach the problem more generally. While a lot of iOS extensions are supported by vs/.net, some of them are not (widget, watch app). Beside that there are SwiftUI frameworks with no objc support (Swift Charts) and swift frameworks (WidgetCenter) which are not bindable easily as you wrote. If there was a "shadow" (or runner is flutter's case) xcode project, one could create widget, watch app, bind swift, swiftui frameworks in that project and then use that from the main .net project. (Something like Microsoft.Maui.Platform.Channels). This approach would help at least with these things:

1. be able to call any swift code with almost any return type from an xcode project, without slim binding. I think, Microsoft.Maui.Platform.Channels covers this.
2. have support in csproj for the xcode Products. For example, like AdditionalAppExtensions for widgets just for watch apps.

[chamons]

SwiftUI frameworks with no objc support (Swift Charts)

You should be able to host those in a https://developer.apple.com/documentation/swiftui/uihostingcontroller and return that (in the future once we have a good way to expose UIView).

Something like Microsoft.Maui.Platform.Channels). This approach would help at least with these things:

Integration of this instrastructure with that is already actively being researched. This likely feels "half-finished" because it is - the team wanted to get this approach out there to unblock people before all of the research was completed.