Swift on Windows: A year of refinement
Speaking in Swift by The Browser Company
SubscribeSign in
Swift on Windows: A year of refinement
The Browser Company<br>Jul 29, 2026
Share
A year ago, Swift on Windows had proven itself in production. Teams were shipping applications across AMD64 and ARM64—from UI-heavy clients to command-line applications exercising substantial portions of the stack. Some deployments used C++ for networking, while others relied directly on Foundation’s URLSession. These real-world workloads surfaced subtle issues that helped drive stability improvements, though a few rough edges remained.<br>But ‘working’ isn’t the same as being predictable — and predictability is what makes a system usable at scale. The past twelve months have not been about adding flashy new features but about refinement : reducing fragility, improving the developer experience, and lowering the cost of adoption.<br>This post walks through the year’s major improvements: rebuilding the runtime build system to establish a reliable foundation, creating the Experimental Swift SDK with multiple distribution models, implementing static linking for self-contained deployments, and validating the approach with production tools.<br>The Dependency Chain
The year’s work tackled three interconnected problems: runtime selection surprises, fragile build configurations, and linkage mismatches. These had to be addressed in dependency order, making the toolchain’s build, packaging, and linking assumptions explicit at each step.<br>We started by rebuilding the runtime build system around modern CMake, because the SDK packaging and linking enhancements only makes sense if the runtime build is reproducible across variants.<br>On that foundation, we defined the Experimental Swift SDK as a single, well-specified deliverable so the distribution and linkage models were encoded, not environment-dependent. With the SDK’s layout in place, we corrected Windows DLL entry-point and import/export semantics. A dynamic-only configuration could still work despite mismatches, but it paid for that convenience with extra thunks and noisy linker output. Static linking forces the toolchain to model those decisions explicitly.<br>Finally, we validated this approach by shipping and running real tools in multi-toolchain environments, where runtime mix-ups happen under normal developer/CI setups.<br>Where We Started: Capable but Costly
Before this work, Swift on Windows was production-ready but costly. The gaps were in ergonomics and platform-specific surprises that raised the cost of adoption. A concrete example: tools built with toolchain X would bind to runtime Y at execution time because DLL discovery relied on Path ordering. Here, “runtime” includes the standard library, the core runtime DLLs, and corelibs (Foundation, Dispatch). In multi-toolchain environments, this was not hypothetical—it was routine.<br>Rebuilding the Foundation: A Modern Runtime Build System
The runtime and compiler are deeply intertwined, built using a bespoke system that accumulated platform-specific logic over a decade. It worked, but it did not cleanly express how the runtime should be built.<br>Early last spring, engineers from The Browser Company began collaborating with Apple and the broader community to rewrite the build system using modern CMake. With proper Swift language support now available in CMake, we could build the runtime in a standalone manner using the target-based modern CMake model.<br>Build configuration matters here: dropping a linker or compiler flag can change optimization behavior (including LTO) in ways that only show up in some configurations. Because the migration is still ongoing across platforms, we keep the legacy and CMake build semantically aligned as runtime changes land.<br>We hit this directly during the transition: one configuration accidentally left a memory-clobbering debug option enabled, and runtimes immediately became slower—slow enough that we did not need benchmarks to know something was wrong. That experience reinforced why the build system rewrite matters: it is not just about “can we build it,” it is about making the runtime’s configuration inspectable so subtle changes do not silently ship.<br>The rewrite also made previously awkward configurations practical, including cross-compilation. The CMake build now supports Darwin and Windows hosts, and we use it to build the Android runtime on Windows. The result is a build that’s easier to audit and less likely to hide configuration drift.<br>Introducing the Experimental Swift SDK
Building on this foundation, we created the Experimental Swift SDK for Windows—a new incarnation of the Windows Swift SDK that packages the runtime, core libraries, and integration metadata as a single artifact supporting multiple distribution models: static distribution, side-by-side installation, or bundling a private copy of the shared runtime.<br>The SDK is the Swift layer that augments the Windows SDK with everything needed to build and run...