Swift interop without ObjectiveC Headers

[kusc-leica]

Apple platform

iOS

Framework version

net8.0-*

Affected platform version

VS 2022, .net 8

Description

Background

iOS development is moving more and more away from ObjectiveC towards Swift. Library authors gradually stop supporting ObjectiveC interop and some language features like structs cannot even be supported through ObjectiveC. For ObjectiveC you can then use tools like Objective Sharpie to auto-generate some binding parts.

It seems the only way to do interop, requires MAUI developers to create their own interop library, redeveloping the API surface of the Swift library and maintining it.

This does not seem like a sustainable path to the future and leads to a problem in the iOS+MAUI ecosystem. Looking to Android+MAUI things are super easy to manage thanks to the nature of Java Interop.

What's next?

I was wondering if there is anything on the roadmap or alternative tooling which solves this problem? I am not that deep into the MAUI+iOS domain so bare with my lack of insights.

The key question is: Is MAUI maybe capable of using Swift libraries if you manually curate some binding code? Looking at the .abi.json files shiped for .swiftmodule you could easily generate some C# glue code like Objective Sharpie. But I wonder about at least two things:

• Can MAUI safely call the Swift library during runtime and handle required marshalling and typing like for ObjectiveC stuff?
• What if we have multiple ABIs, are there annotations for managing bindings matching the runtime platform (e.g. if mangled names are different)?

Maybe there is already some tooling in the Market I have overseen?

Steps to Reproduce

1. Take a Swift only iOS library like https://github.com/Notificare/notificare-sdk-ios (https://cdn.notifica.re/libs/ios/4.0.0/cocoapods.zip) which uses Swift features like protocols, classes, enums, extensions and structs.
2. Try to create a MAUI binding library without relying on the .h files as they do not contain all types.

Did you find any workaround?

As mentioned above the api.json look very promising to do some code generation. But creating some code generator requires good knowledge about ABIs, calling conventions, .net runtime support (e.g. when inheriting classes and implementing interfaces)

Build logs

No response

[rolfbjarne]

Unfortunately binding swift is much more complicated than it may sound at first, but the good news is that support for swift is ongoing in the dotnet/runtime repository (see https://github.com/orgs/dotnet/projects/375 for an overview).

It's still a ways away though, but in the meantime, the workaround is to expose Swift to Objective-C, and then bind that Objective-C API. For Swift APIs that you don't control, you can wrap them in your own Swift APIs and then expose those to Objective-C.

[kusc-leica]

The project you have linked is not public. Beside some issues and experimental projects I couldn't find any official documentation or statement around the exact plans. Things might happen behind the scenes but its hard from outside to judge the complexity, state and needs. Even though there were items like dotnet/runtime#93631 there isn't even something mentioned in https://learn.microsoft.com/en-us/dotnet/maui/whats-new/dotnet-9?view=net-maui-8.0

Unfortunately, in our case, it is not in our control to expose things to ObjectiveC as we are not the author of the library. Also it is not realistic to maintain the whole 3rd party wrapper ourselves.

[rolfbjarne]

The project you have linked is not public.

Sorry about that, all the work is done in public, so I assumed the project was as well, but I was wrong.

Here are a couple of dotnet/runtime issues related to Swift support, you can also search for "swift" there.

• Runtime support for Swift Interop in .NET 10 dotnet/runtime#108662
• Projection tooling for Swift interop in .NET 10 dotnet/runtime#95633

Even though there were items like dotnet/runtime#93631 there isn't even something mentioned in learn.microsoft.com/en-us/dotnet/maui/whats-new/dotnet-9?view=net-maui-8.0

That's because at this point it's not really useful for public consumption. Hopefully in .NET 10 we'll have something that can be used to bind at least a limited set of Swift APIs.