Swift/WinRT

A Swift projection for WinRT APIs, written in pure Swift, for consuming modern Windows Runtime APIs, the Windows Application SDK, WinUI and arbitrary WinRT components, or producing your own.

Swift/WinRT consists in:

• A code generator for Swift definitions of WinRT APIs described in .winmd files, based on the swift-dotnetmetadata project.
• Support libraries for projecting COM and WinRT types, and invoking related core platform APIs such as RoInitialize.

For examples of using projections, refer to interop tests.

This project is a pure Swift rewrite of its namesake from The Browser Company.

Feature set

Swift/WinRT should support the majority of WinRT interop scenarios thanks to the following features:

• Swift representation of the full WinRT type system:
  • Core types: boolean, integers, floats, char16, string, guid, IInspectable
  • Type definitions: structs, enums, interfaces (+generic), delegates (+generic), classes (activatable, composable and static)
  • Members (instance and static): constructors, struct fields, enumerants, methods, properties, events
  • Parameters: in, inout, out, and return values
  • Types: arrays, IReference<T> boxing, IAsyncInfo/IAsyncOperation, weak references and collection interfaces
  • Nullability and exceptions
  • Namespaces
• Documentation comment generation from xml documentation
• Interoperability between WinRT objects and COM interfaces
• Implementing COM or WinRT interfaces in Swift objects to be used by WinRT
• Deriving from WinRT composable classes, e.g. for Xaml controls
• Manifest and registration-less WinRT class instantiation
• Opt-in upcasting support, e.g. casting a returned WinRT UIElement to a Button using as

Design philosophy

• Correctness & completeness first: The information loss from WinRT APIs should be minimal, including when this results in less Swifty code. For example, most methods are throwing as to capture any failure HRESULTs, and namespaces are simulated to avoid name clashes. If information loss is desirable for ergonomics, opt-in switches may be provided.

• Readability of projections: The generated types and projection glue code should be as readable as possible to ensure correctness and so that one can easily debug into the generated code as necessary.

• Interoperability with COM: It should be trivial to query WinRT objects for COM interfaces and use them as such. In fact, this project is designed to be extensible to eventually generate COM API descriptions from the Win32 Metadata project or COM type libraries.

• Composability: It should be possible to generate projections for individual assemblies independently and have them interoperate.

• Independence from Windows headers: The generated code should not rely on header files from the Windows SDK, but rather produce any C definitions it requires.