swift-winrt: a Swift projection for the Windows Runtime, built by a browser company

It generates the ABI and the bindings together

swift-winrt is a Swift language projection for WinRT, and the README explains the design in one sentence that carries the whole idea: it generates both the C ABI definition, which is imported into a Swift module, and the actual Swift bindings which call into that ABI.

That is the mechanism, and it is worth unpacking. A Windows Runtime component written in another language exposes a C-style ABI, with vtables, activation factories and IInspectable-style queries. A projection is the layer that lets a modern language treat those components as if they were native. The projection here does not hand-write a Swift wrapper for every API. It emits the C ABI definition as one artefact and emits Swift code that calls into it as another, so the two are guaranteed to match.

The provenance is stated plainly: the project is based on the Microsoft created cppwinrt project and carries the same source structure. cppwinrt is the C++ projection for the same runtime, and porting its structure is what gives the Swift tool the same shape of component model, the same metadata reader and the same understanding of the runtime's type system. Learning the code from cppwinrt is therefore a reasonable route for anyone who knows the C++ side.

The practical consequence for a user is that you need a metadata source to generate from, and the build process produces a response file that says which component to project and where to write the output. The README's debugging section points at that file directly, which tells you the generator is invoked with a response file rather than a long command line.

The licence is BSD-3-Clause, the default branch is main, and the last push was on 2026-10-02.

Four projects, two build systems, and one that calls the other

The project structure section lists four main projects, and the split between C++ and Swift is the organising principle.

SwiftWinRT is the tool itself and is written in C++. TestComponent is a C++ component used as test input. The Swift Bindings directory holds Swift code, and the test app is a Swift application. The README then states the rule: all C++ code is built with CMake, and all Swift code is built with SPM, the Swift Package Manager.

So a Swift package that depends on projected WinRT APIs is built by the Swift toolchain, while the generator and the test component are built by CMake. That division is the reason the repository keeps an integrated build at all.

The integrated build exists because the two halves have to be built in a particular order and the results fed to each other. The README says that while SPM is the driving force for all Swift related code, the project still maintains an integrated build system with CMake, which invokes SPM, and it points at the tests CMakeLists file for the detail. The commands are CMake presets:

cmake --preset debug
cmake --build --preset debug
cmake --build --preset debug --target install

And there is a one-liner variant for PowerShell, which the README explains is missing the configure step on purpose, because you do not want to re-run configure every time.

That single sentence is the entry point to the most important practical detail in the whole project, and it is the one that decides how your inner loop feels.

A pinned Windows SDK and a pinned Swift toolchain

The toolchain is specified to the patch level, which is unusual in a README and tells you how tightly this is coupled to Windows.

CI builds with a released Swift toolchain, and the version is set in the Windows build workflow, currently 6.2-RELEASE. If you need to match a specific build rather than a release, the README points at the swift-build releases, which carries them. So there is a way to get an exact toolchain, and the project uses it.

The Windows SDK is pinned the same way. The CMake presets set the system version to 10.0.26100.0, and the setup instruction is to install that version of the SDK:

winget install --id Microsoft.WindowsSDK.10.0.26100

The submodules come first:

git submodule init
git submodule update --recursive

None of this is exotic, but it does mean the project only builds in a fairly narrow, explicitly specified environment: a Windows machine, a particular SDK build, and a particular Swift toolchain. The SDK version is not a floor but a fixed choice, so a machine with a different SDK installed will not build it without changing the preset.

For a team that wants to contribute, that is a one-time setup cost per machine. For a team that wants to consume the output, it does not matter at all, because consumers of the projection depend on the generated Swift code, not on how it was generated.

The known issue that makes release mode the sane default

The README spends more words on how to build this project than on what it does, and the reason is a known issue that is described with unusual candour.

There is a known issue which causes the swift-winrt build to be dirtied every time, and re-running swift-winrt in debug mode is very slow. The project responds by setting CMAKE_SKIP_INSTALL_ALL_DEPENDENCY in the CMake presets, and the guidance follows: when you can, building and testing in release mode will be quicker, and generally that is the golden path for when you do not need to debug tests. If you do need to debug the tests, you will probably want to build debug.

The mechanism behind the fix is worth understanding, because it explains the whole workflow. The generator is a C++ program, and the CMake dependency graph is such that the generator is considered out of date on every build, so it reruns, and the generator is the slow part. Skipping the install-all dependency step prevents that churn for the incremental case. The price is that when the generator genuinely does need to rerun, you have to ask for it deliberately.

That is why the recommended workflow is a split, and the README spells it out. You open the swiftwinrt directory in Visual Studio and select the release configuration, and you open VS Code at the root of the repository with the Debug preset selected. The stated benefits are that you can quickly re-run swift-winrt in release mode when needed while still building only debug for the tests, and that controlling when the generator runs lets you hand-edit files to prototype with APIs.

There is a warning attached: you have to be careful that when you are done iterating, especially on handwritten changes, you run a full build, and your pull request will fail if this does not happen.

Two editors, one response file

The debugging section splits the project between two development environments, and understanding why saves a lot of confusion.

For the Swift test code, VS Code is the tool. The README says the test code is easily buildable and debuggable there, with Ctrl+Shift+B to build and F5 for the standard debug window. The important note is that when building tests in VS Code, swift-winrt is not re-run, because that only runs the SPM portion of the build. So the fast inner loop leaves the generator alone.

For the generator itself, the README is unambiguous: use full Visual Studio, not VS Code, and open the swiftwinrt CMake file in it. The build process generates a .rsp file which can be used to easily generate the bindings, so the first step is to run a build so that the file exists. Then you select swiftwinrt.exe as the startup project and point the debug arguments at that response file, through the Debug and Launch Settings for swiftwinrt panel, with the configuration in a JSON file that names the project, the target and the argument path.

So the two-editors split is not preference, it is division of labour. VS Code owns the Swift half and the fast test loop, Visual Studio owns the C++ generator and the deliberate, slow regeneration of the bindings.

The repository layout matches: a .vscode/ directory for the editor configuration, a cmake/ directory, the swiftwinrt/ directory for the generator, tests/ for the component, bindings and application, and a nuget/ directory for the packaged output, plus a CMakePresets.json at the root, a license.txt, an AGENTS.md and a .gitmodules file.

Editorial conclusion

Adopt swift-winrt if you are writing Swift on Windows and need to reach Windows Runtime APIs that Swift cannot name directly, since the projection generates both the ABI and the Swift side for you. Do not adopt it as a general interop layer, because the toolchain it needs is Windows specific and the build is pinned to one SDK version and one Swift release. Before you start, read the developer workflow section rather than the overview, because the recommended debug and release split is what makes the build usable, and remember that the last push was on 2026-10-02 against a single release tag, v0.1.396, so treat the project as a component to vendor rather than a dependency to track.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-3-Clause
3. README
4. Releases
5. thebrowsercompany/swift-winrt on GitHub