Implement .NET Swift interop support targeting Apple platforms

[kotlarmilos]

Goal

The primary goal is to ship projection tooling along with corresponding runtime support that have ability to generate C# bindings for Swift. Our objective is not full Swift support, but a targeted approach based on specific use-cases.

Swift has richer semantics than .NET, and experimentation in the previous release has shown that achieving full Swift interop would take several releases.

As the primary users will be from the .NET ecosystem, our goal is to focus on functionality, ensuring that the generated bindings resemble C# patterns rather than aiming for a Swift-like experience. As MAUI is the default framework used for mobile development within the .NET ecosystem, all examples will be based on it.

Motivation

The Swift programming language has a different ABI, runtime environment, and object model, making it challenging to call into from the .NET runtime. Apple's shift towards Swift highlights the importance of MAUI being compatible with Swift libraries and frameworks to remain relevant in the Apple ecosystem. Ideally, the interop should operate with a minimal set of additional wrappers and enable direct calls to various Swift functions.

Plan

This project is divided into three user-stories.

Runtime: At the lowest level, ensuring that Swift can be called from .NET without an intermediate step through C or Swift. The support must be implemented across all supported .NET runtimes targeting macOS and Apple mobile platforms.

Code-Generation: This layer involves the generation of C# bindings for Swift. The projection tooling consists of importing Swift into .NET, exporting .NET to Swift, and tooling distribution.

End-user scenarios: At the highest level, we are driven by defined examples. For example, a MAUI iOS developer should be able to create an iOS app that interacts seamlessly with Swift libraries and frameworks. The primary goal at this level includes defining the scope of the work.

.NET 9

We’ve introduced types for .NET interop with Swift code. The projection tooling can generate bindings for structs and enums with static methods.

.NET 10

In this release, we will focus on essential language features only based on the specific use-cases.

User stories

• Use-cases for Swift interop in .NET 10 #95636
• Projection tooling for Swift interop in .NET 10 #95633
• Runtime support for Swift Interop in .NET 10 #108662

[ghost]

Tagging subscribers to this area: @dotnet/area-meta
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Overview

The Swift programming language has a different ABI, runtime environment, and object model, making it challenging to call into from the .NET runtime. The goal is to establish .NET Interop support in the ecosystem and address Swift ABI differences. Apple's shift towards Swift highlights the importance of Maui being compatible with Swift libraries and frameworks to remain relevant in the Apple ecosystem. Ideally, the interop should operate with a minimal set of additional wrappers and enable direct calls to various Swift functions.

This project can be divided into at least three separate areas and therefore potentially three separate workstreams.

Runtime: At the lowest level, ensuring that Swift can be called from .NET without an intermediate step through C or assembly is essential. This task must be implemented across all supported .NET runtimes targeting OSX and Apple mobile platforms.

Code-Generation: This layer involves the generation of C# bindings for Swift. The projection tooling consists of importing Swift into .NET, exporting .NET to Swift, and tool distribution.

End-user scenarios: At the highest level, it is crucial to address end-user scenarios. For instance, a MAUI-iOS developer should be able to create an iOS app that interacts seamlessly with Swift libraries and frameworks. The primary task at this level includes defining and managing the end-to-end process. This includes prioritizing Swift libraries and showcasing the support for .NET Swift interop.

User stories

• Runtime support for Swift Interop in .NET 9 #93631
• Projection tooling for Swift interop in .NET 10 #95633
• Use-cases for Swift interop in .NET 10 #95636

Author:	kotlarmilos
Assignees:	kotlarmilos
Labels:	Epic, area-Meta, tracking
Milestone:	9.0.0

[ghost]

Tagging subscribers to 'os-ios': @steveisok, @akoeplinger, @kotlarmilos
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Overview

The Swift programming language has a different ABI, runtime environment, and object model, making it challenging to call into from the .NET runtime. The goal is to establish .NET Interop support in the ecosystem and address Swift ABI differences. Apple's shift towards Swift highlights the importance of Maui being compatible with Swift libraries and frameworks to remain relevant in the Apple ecosystem. Ideally, the interop should operate with a minimal set of additional wrappers and enable direct calls to various Swift functions.

This project can be divided into at least three separate areas and therefore potentially three separate workstreams.

Runtime: At the lowest level, ensuring that Swift can be called from .NET without an intermediate step through C or assembly is essential. This task must be implemented across all supported .NET runtimes targeting OSX and Apple mobile platforms.

Code-Generation: This layer involves the generation of C# bindings for Swift. The projection tooling consists of importing Swift into .NET, exporting .NET to Swift, and tool distribution.

End-user scenarios: At the highest level, it is crucial to address end-user scenarios. For instance, a MAUI-iOS developer should be able to create an iOS app that interacts seamlessly with Swift libraries and frameworks. The primary task at this level includes defining and managing the end-to-end process. This includes prioritizing Swift libraries and showcasing the support for .NET Swift interop.

User stories

• Runtime support for Swift Interop in .NET 9 #93631
• Projection tooling for Swift interop in .NET 10 #95633
• Use-cases for Swift interop in .NET 10 #95636

Author:	kotlarmilos
Assignees:	kotlarmilos
Labels:	Epic, area-Meta, tracking, os-ios
Milestone:	9.0.0

[ShikiSuen]

Sorry for the interruption, but macOS is not OSX anymore.
The major version of macOS changed since 2020.
It is more appropriate to use the term macOS instead.

[kotlarmilos]

Thanks for your suggestion. The label description mentions macOS aka OSX. @marek-safar, please inform us if we should make any changes.

[marek-safar]

Mixing macOS and Apple seems odd. What about just naming explicitly macOS and iOS ?

[jkotas]

What about just naming explicitly macOS and iOS ?

macCatalyst and tvOS too

We call these "Apple platforms" in many places in the repo, one example from many

runtime/src/libraries/System.Private.CoreLib/src/System/OperatingSystem.cs

Line 245 in 867250c

internal static bool IsApplePlatform() =>

.

[ShikiSuen]

@jkotas These platforms have differences in available frameworks.
AppKit and InputMethodKit are only available on macOS.

If there is a dotNET equivalent of Swift #if canImport(XXXKit) then it should be fine.

[Noemata]

Is the .Net 9 Swift interop facility usable on Windows? I would like to use the same code on both Mac and Windows to integrate with Swift libs on both now that the Swift compiler has reached a feasible level of maturity on Windows. If so, are there any examples out there that demonstrate integration with C# and Swift interop on Windows? If not, why is Swift compiler integration not supported on Windows? Lastly, I am aware that Swift on Windows now provides interoperability with Clang/C++, so I'm not looking at that as an alternative given the advantages of the .Net 9 approach for Swift interop.

[jkotas]

Is the .Net 9 Swift interop facility usable on Windows?

Swift interop is Apple-specific for now to reduce scope of the project. Swift interop is a multi-year project even with this scope reduction. Nothing fundamental prevents us from enabling the swift interop on other OSes in future.

[Noemata]

@jkotas , "Swift interop is Apple-specific for now to reduce scope of the project." So is that a "no", for Swift interop on Windows with .Net 9? I don't know enough about how Swift manifests like capabilities on Windows, but given where Swift is today in terms of code "safety", it does appear to be one of the best choices for cross platform low level lib development. Thus, I would think Swift compiler interop support on Windows should have equal if not higher priority to interop on Apple's eco system, especially given this further elevates C# viability across OS variants. Please clarify when and if we can expect Swift interop support on Windows. Please don't cripple us on Windows!

[jkotas]

Swift interop is Apple-specific for now to reduce scope of the project." So is that a "no", for Swift interop on Windows with .Net 9?

Right. Note that Swift interop support in .NET 9 is very limited and most of it is experimental. It is far from complete and usable for most real-world APIs.

I would think Swift compiler interop support on Windows should have equal if not higher priority to interop on Apple's eco system,

I disagree. Swift is by several orders of magnitude more popular in Apple eco system than anywhere else. It is why we have prioritized Apple support. We (the core .NET runtime team) do not have infinite resources that forces us to do prioritization decisions like this one.

Please clarify when and if we can expect Swift interop support on Windows

It is not going to be in .NET 10 and we do not have detailed plans beyond that.

.NET runtime is open-source project that accepts contributions. If you care about Swift interop on Windows a lot, you may consider contributing the implementation (https://github.com/dotnet/runtime/blob/main/CONTRIBUTING.md#dos-and-donts are our contribution guidelines).

[Noemata]

@jkotas, agree, Swift is clearly more popular on Apple for obvious reasons. However, this tendency of Microsoft to quarantine its own platform isn't helping the cause. It's getting excessively easy to feel like an orphan being a developer on Windows. WPF / Xamarin / UWP / WinUI / MAUI is not a happy evolution to date. Enterprise clients in particular are being forced to look beyond Windows as a result. Thank you for the quick reply. Please do reconsider your stance.