SwiftPM on Swift Build - October Update

Development Package Manager
,
1

SwiftPM on Swift Build - October Update

Back in February, we open sourced Swift Build with the goal of adopting it as SwiftPM's unified cross-platform build system implementation. I'd like to share a quick collection of updates on the progress towards that goal we've made so far, and plans for the remaining work. Feel free to use this thread to ask any questions you have!

Trying it out

First things first - You can try out the new build system backend today by passing --build-system swiftbuild when invoking SwiftPM. Currently, I recommend trying this out in a recent nightly-main snapshot, as bug fixes and improvements continue to land daily.

While there remain a number of known issues and some missing features when enabling this backend, it's now capable of building many existing packages on Linux, Windows, and macOS. Feel free to try it out and file issues for any bugs you encounter with your own packages! Early feedback is very much appreciated to help ensure these are tracked and addressed.

Notable recent changes and improvements

When we announced Swift Build, we laid out two goals for replacing SwiftPM's native build system: feature parity and platform support parity. Since then, we've made significant progress in both areas. Some notable changes include:

The full list is too large to list here, but I want to thank everyone who's contributed to the project thus far through pull requests, feedback, and bug reports. Getting to this point has been a real team effort.

Up next

Our goal with this work has been to standardize on Swift Build as SwiftPM's single cross-platform build system implementation. In addition to performance and reliability benefits, completing this transition is also a prerequisite for adding user-facing SwiftPM features which depend on the new backend's improved flexibility and capabilities.

There are a few steps required to execute this transition at a high level:

  1. Complete the work to reach platform-support and feature parity with SwiftPM's existing build system and recommend it to all SwiftPM users in 2026H1
  2. Enable --build-system swiftbuild as SwiftPM's default build system backend and deprecate the current default build system
  3. Remove SwiftPM's current default build system implementation in 2026H2

Tracking progress

We've spun up a new GitHub project dashboard - SwiftPM on SwiftBuild - where you can follow the progress and engage with developers on the issues. Keep an eye out for anything labeled “good first issue” as they are often a great starting point if you're interested in contributing.

50 Likes
2

This is looking great! Any idea if there's a way to get Xcode's SPM integration to use the --build-system flag or otherwise turn on swift-build support? Or are we still limited by Xcode not using the toolchain's SPM integration?

3

Xcode's SPM integration has always used Swift Build, so there is no switch needed.

4

Well that's unfortunate, as I'd hoped the integration of swift-build would fix the various issues Xcode has with packages. This includes, but is not limited to building swift-syntax for Intel when used in macros (which was specifically called out as only fixable in SPM when moving to swift-build), building all packages for Intel on AS machines when a project has a iOS app with embedded watch target, and the inability to reliably use the same package from an iOS app and a dynamic framework embedded within that app.

More generally, I had hoped this would allow Xcode to more directly integrate with SPM, and enable things like passing build settings, especially active compilation conditions, or give Xcode direct control over how packages are built (forcing dependencies to build dynamically is often needed to fix the final issue I mentioned above). I guess these have always been Xcode limitations, which is supremely disappointing.

4 Likes