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:
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.
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.