C# and Swift bridge?


I have an app for macOS which I would like to port to Windows.

The app takes advantage of heavy Cocoa UI libraries, therefore I would like to rebuild the UI in Windows native technology (probably C# + WPF).

I would like the business logic to remain in the Swift language and my question is:
How could I accomplish that?

I would like C# code to interact with Swift windows compiled code.

Any options to build a bridge between them and make them communicate?

Thank you very much in advance,

I did this in the past (although instead of Swift that was cross platform C/C++ with C# on Windows) and from a personal experience I would not recommend doing that - the cost you save for not duplicating the common logic would be out dwarfed by the cost of the bridge solution (runtime overhead of marshalling data back & forth, GC vs ARC differences, optional differences, enum differences, reference vs value semantic difference for arrays/dictionaries, harder maintenance, extra layers of cross platform logic complexity, more complex debugging, smaller pool of people to hire from, higher development costs, etc).

If you still want to go, try some minimal round trip test (WPF app calling swift method with a few parameters, and swift code in turn calls C# method with a few parameters, where parameters are these to make the test more or less realistic:

func foo(String, [String], [String: String], Data) -> (Int, Double)

also consider the case of escaping callbacks.

Have you considered using SwiftWin32 for the Windows UI? It's maintained by a member of the Swift Core Team and it'll probably be easier than trying to interoperate between C# and Swift.


I second using SwiftWin32. Iā€™m planning to use that for a Windows port of a Swift project myself. It feels like a cross between SwiftUI and MFC.

I think it might be relevant to cc @migueldeicaza, who has worked on a Swift to .NET binding


We have a tool that binds Swift libraries and exposes it to .NET here:

That said, it is intended to be used on MacOS for interoperatbility with iOS at this point, so using it outside of that space is likely going to include a lot of tinkering on your part. It does not do a full Swift binding yet (it is quite comprehensive, but not full).

The major challenge that you will face with the above tool, if you can get it to run on Windows and into your pipeline is that if there are issues, hacking that tool to address them is a lengthy process. Not impossible, but not trivial either.

I say the above to propose that what you could do is surface your Swift business logic as a callable C API, and then manually bind that C API with .NET's [DllImport].

At that point you can write your UI for one of the many Windows UI frameworks (WinUI, WPF or WinForms).

While I am a big fan of the work going on with SwiftWin32, I think that it is still in its infancy (like our Swift binding tool) which might require some tinkering and it also surfaces the old-style Win32 API (on the one hand, great, it is very stable, on the other one, not very sophisticated compared to WinUI).

The approach that is the most straight-forward, reliable and fully within your control, although tedious is the C bridge approach. I would do this is you must ship a working piece of software today.

The others two are suitable if you are hacking at your leisure for personal enjoyment, and they could be part of a new learning adventure.



You might also consider


or the more mature


if you need to ship your existing swift business logic in a dotnet world