Swift/Win32: bringing an MVC shape to the Win32 API in Swift

MFC for Swift, and what that comparison claims

Swift/Win32 is described as a Windows application framework for Swift, and the README states its aim directly: to provide an MVC model for writing applications on Windows, with Swift friendly wrapping of the Win32 APIs much like MFC did for C++.

That comparison is the whole positioning, and it is worth reading carefully. MFC, the Microsoft Foundation Class Library, wrapped the Win32 API in C++ classes so that a Windows programmer did not have to hand-manage handles, message pumps and window procedures. Swift/Win32 aims at the same thing for Swift, and it aims at the same thing as well in a narrower way: a working application, with a model, a view and a controller, rather than a general purpose C++ framework with an enormous surface.

The project is BSD-3-Clause licensed, the primary language is Swift, and the last push to the main branch was on 2026-10-16, with no GitHub releases. The homepage is compnerd.github.io/swift-win32, and the topics list covers swift, swift-windows, systems, ui, win32 and windows.

The repository layout shows a mature package rather than a prototype. There is a Sources/ tree, Tests/, Examples/ with a Calculator and a UICatalog application, a Packages/ directory for what are presumably separate Swift packages, a Package.swift plus a series of version-specific manifests from [email protected] through [email protected], a CMakeLists.txt with CMakePresets.json, a cmake/ directory, a Documentation/ folder, and a .swift-format configuration.

Building it with CMake, and the manifest step that surprises people

The build requirements are Swift 5.4 or newer, Windows SDK 10.0.107763 or newer, and CMake 3.16 or newer. The README lists the ways to get a toolchain: the snapshot binaries from swift.org, the nightly build from Azure, or building the Swift compiler from source.

The recommended path is CMake, and the example session is short enough to copy:

cmake -B build -D BUILD_SHARED_LIBS=YES -D CMAKE_BUILD_TYPE=Release -D CMAKE_Swift_FLAGS="-sdk %SDKROOT%" -G Ninja -S .
ninja -C build SwiftWin32 UICatalog

%CD%\build\bin\UICatalog.exe

The detail that catches people is in the collapsible section under it. The CMake build automatically performs application manifest merging via the mt tool, which is part of the Visual Studio build tools, so you must run the build under the x64 Native Tools Command Prompt for VS2019, or the appropriate shell for your version of Visual Studio. There is a second warning as well: the Swift installer adds environment variables, so you need to restart your terminal after installing the toolchain to pick them up.

Both of those are environment problems rather than code problems, and both produce a confusing failure if you do not know about them. The manifest merging in particular is not optional decoration, it is what makes the built application carry the right manifest resource, and the build does it for you only if the Visual Studio tools are on the path.

The swift build target names in the command are the two products, SwiftWin32, which is the framework itself, and UICatalog, which is one of the demo applications.

Swift Package Manager, and the two things it cannot do

Building with Swift Package Manager is supported, although CMake is recommended for ease. The README gives two reasons to care about the SPM path anyway. The SPM build is required for code completion through SourceKit-LSP, and it allows Swift/Win32 to be used in other applications that use SPM.

Those are real advantages, and the price is a set of documented limitations. It is not possible to deploy the auxiliary files which Swift/Win32 based applications need to function to the correct location. And it is not possible to build and run multiple demo projects, because the auxiliary files collide.

The workaround is a set of manual post-build steps, which the README spells out:

swift build --product UICatalog
mt -nologo -manifest Examples\UICatalog\UICatalog.exe.manifest -outputresource:.build\x86_64-unknown-windows-msvc\debug\UICatalog.exe
copy Examples\UICatalog\Info.plist .build\x86_64-unknown-windows-msvc\debug\
.build\x86_64-unknown-windows-msvc\debug\UICatalog.exe

Reading those three commands tells you a lot about the state of the project. The manifest has to be embedded into the executable by hand with the mt tool, because SPM will not do it. The Info.plist has to be copied into the build directory by hand, because SPM will not place it. And then the executable is run straight from that build directory.

Three manual steps to produce a working application is the honest cost of the SPM route, and the reason CMake is the recommendation is right there in the commands. The mt tool also needs the x64 Native Tools Command Prompt for VS2019 to be available, which is the same environment requirement as the CMake path.

The demo applications and the package manifests

Two parts of the repository tell you what the framework is meant to be used for.

The first is the Examples/ directory, which contains a Calculator and a UICatalog application. A Calculator is the traditional hello world for a windowing framework, because it exercises a window, a menu, a control, a message loop and input, and none of it needs to be interesting. UICatalog is the more revealing of the two, since a catalog application is by nature a browser over a list of items with a detail pane, which is the layout shape most real Windows applications have.

The Examples directory has its own CMakeLists.txt, so the demos are built as part of the CMake project rather than as an afterthought, and the UICatalog executable is the one the README's build command actually produces and runs.

The second part is the set of package manifests. There is a Package.swift plus [email protected], [email protected], [email protected], [email protected] and [email protected]. Swift Package Manager selects the version-specific manifest that matches the toolchain in use, and shipping one per supported version is how a package declares different dependency requirements or different platform settings for older compilers.

Given that the build requirements name Swift 5.4 as the floor, the presence of manifests from 5.4 through 5.8 is consistent with a project that still supports a range of toolchains rather than only the newest one. The Packages/ directory alongside the single Package.swift suggests the framework is split into several Swift packages, which is what lets a consumer depend on one part of it through SPM without pulling the whole tree, the same reason the README gives for supporting the SPM build at all.

Unimplemented interfaces that abort, and the flag that gets you past them

The testing section is the most valuable paragraph in the README, because it tells you what state the framework is actually in.

The current implementation is still under flux and many of the interfaces expected to be present are not yet implemented. Because clearly indicating the missing surface makes it easier to focus on what needs to be accomplished, there are many instances of interfaces being declared but not implemented, and most of these sites will abort if they are reached.

That is an unusual thing for a project to publish, and a good one. A framework where a declared method exists in the type system and then aborts at run time is a trap for anyone reading the interface as a promise. By saying so explicitly, the project is telling you that the surface area you see is aspirational and the implemented part is smaller.

To let you test the parts that are implemented, there is a special condition called ENABLE_TESTING which bypasses the missing functionality, and you pass it as a flag to the Swift Package Manager test command:

swift test -Xswiftc -DENABLE_TESTING

So the testing story is coherent. The unimplemented paths abort by default, which means a real application run fails loudly rather than silently misbehaving, and the flag exists so that the test suite can exercise the implemented surface without tripping over a declaration that has no body behind it.

For an adopter, the practical consequence is that the type signatures are a roadmap rather than a contract, and the README says so in as many words.

Editorial conclusion

Adopt Swift/Win32 if you want to write a native Windows application in Swift and need the Win32 API wrapped in Swift types rather than called through raw pointers, because that is exactly the layer this project provides. Do not adopt it as a finished framework, since the README states plainly that many expected interfaces are declared but not implemented and will abort if reached, and that the implementation is still under flux. Before you build, use the CMake path rather than Swift Package Manager, because the SPM build cannot place auxiliary files or build several demo projects at once, and run the tests with `swift test -Xswiftc -DENABLE_TESTING` so the unimplemented paths do not abort your run.

Frequently asked questions

Official sources

1. compnerd/swift-win32 on GitHub
2. Issues
3. License: BSD-3-Clause
4. Project website
5. README