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 separate work-streams.

Runtime: At the lowest level, ensuring that Swift can be called from .NET without an intermediate step through C or assembly. 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 oriented towards end-user scenarios. 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.

User stories

• Use-cases in .NET 9
  • Review projections of Swift generics in C# for CryptoKit dev template runtimelab#2580
  • [Discussion] Generate C# bindings for CryptoKit framework runtimelab#2583
  • [Discussion] Generate C# bindings for Foundation framework runtimelab#2584
  • [Discussion] Generate C# bindings for SwiftUI framework runtimelab#2594
• Projection tooling in .NET 9
  • Add .NET Swift interop tooling components and layout designs#312
  • Review UX and bindings for .NET Swift interop tooling in simple P/Invoke void cases runtimelab#2518
  • Review UnsafeRawPointer projections in C# for CryptoKit dev templates runtimelab#2529
  • Review struct and enum projections in C# for CryptoKit dev templates runtimelab#2533
• Runtime support for Swift Interop in .NET 9 #93631

.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

Future

This work is planned for future releases.

User stories

TBD

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