SwiftPM development update: default build system change

owenv · March 24, 2026, 5:56pm

This is a PSA that as of https://github.com/swiftlang/swift-package-manager/pull/9661, we have switched SwiftPM's default build system over to --build-system swiftbuild on the main branch (--build-system native remains available to restore previous behavior). This has passed PR testing, compiler smoke testing, toolchain builds, and our own compatibility testing against the Swift Package Index. However, with a change like this, there's always a possibility for some unanticipated issues to pop up. If you do notice any issues or impact to your workflows, please file issues on the SwiftPM repo with either the "swift build" label or some indication in the title - we will be treating these as very high priority. For urgent issues, I can be reached directly by forums DM.

Thanks,
Owen

Relevant changes:

3405691582 · March 24, 2026, 6:26pm

Looks like I've got to go back and make sure swift-build works on OpenBSD again. Last I checked there was some work to do there.

Is there something that tracks the eventual flip of this to the release branches? Or are we sort of pitching this towards 6.5 eventually?

owenv · March 24, 2026, 6:36pm

Since 6.4 has not branched yet, we expect this change to be on that branch once it’s created. I’m not aware of specific issues on OpenBSD right now, but FreeBSD has received more attention in comparison. Happy to take a look if you run into any issues

Sarunas · March 25, 2026, 12:30pm

Hi @owenv !

What would be needed for supporting XCFrameworks?
Happy to enable this by default in the nightly CI as soon as we can compile our code base.

6.3 gives currently:

error: Multiple commands produce OrdoEssentials.framework
warning: duplicate output file OrdoEssentials.framework/Versions/A on task: Copy .build/artifacts/ordo-sdk/OrdoSDK-OrdoEssentials/OrdoEssentials.xcframework/macos-arm64/OrdoEssentials.framework

Also looking forward for CAS caching to be enabled via this change!

Looks to be related:

github.com/swiftlang/swift-package-manager

[Parity] error: Multiple commands produce

opened 06:36PM - 18 Sep 25 UTC

kcieplak

bug build system swift build swiftbuild backend

### Is it reproducible with SwiftPM command-line tools: `swift build`, `swift te…st`, `swift package` etc? - [x] Confirmed reproduction steps with SwiftPM CLI. The description text _must_ include reproduction steps with either of command-line SwiftPM commands, `swift build`, `swift test`, `swift package` etc. ### Description https://github.com/getsentry/sentry-cocoa.git MacOS The following package does not build using the 'swifbuild' backend but does with 'native' ``` swift build `--buildsystem=swiftbuild` fails to build package ``` ``` error: Multiple commands produce '/private/var/lib/jenkins/workspace/swift_oss/swift-package-index-metrics@4/spi-workdir/D071710C-D745-481C-B50A-068827E39F1C/sentry-cocoa/.build-swiftbuild/arm64-apple-macosx/Products/Debug/Sentry.framework' info: Command: ProcessXCFramework /private/var/lib/jenkins/workspace/swift_oss/swift-package-index-metrics@4/spi-workdir/D071710C-D745-481C-B50A-068827E39F1C/sentry-cocoa/.build-swiftbuild/artifacts/sentry-cocoa/Sentry-Dynamic-WithARM64e/Sentry-Dynamic-WithARM64e.xcframework /private/var/lib/jenkins/workspace/swift_oss/swift-package-index-metrics@4/spi-workdir/D071710C-D745-481C-B50A-068827E39F1C/sentry-cocoa/.build-swiftbuild/arm64-apple-macosx/Products/Debug/Sentry.framework macos info: Command: ProcessXCFramework /private/var/lib/jenkins/workspace/swift_oss/swift-package-index-metrics@4/spi-workdir/D071710C-D745-481C-B50A-068827E39F1C/sentry-cocoa/.build-swiftbuild/artifacts/sentry-cocoa/Sentry-Dynamic/Sentry-Dynamic.xcframework /private/var/lib/jenkins/workspace/swift_oss/swift-package-index-metrics@4/spi-workdir/D071710C-D745-481C-B50A-068827E39F1C/sentry-cocoa/.build-swiftbuild/arm64-apple-macosx/Products/Debug/Sentry.framework macos info: Command: ProcessXCFramework /private/var/lib/jenkins/workspace/swift_oss/swift-package-index-metrics@4/spi-workdir/D071710C-D745-481C-B50A-068827E39F1C/sentry-cocoa/.build-swiftbuild/artifacts/sentry-cocoa/Sentry/Sentry.xcframework /private/var/lib/jenkins/workspace/swift_oss/swift-package-index-metrics@4/spi-workdir/D071710C-D745-481C-B50A-068827E39F1C/sentry-cocoa/.build-swiftbuild/arm64-apple-macosx/Products/Debug/Sentry.framework macos error: Multiple commands produce '/private/var/lib/jenkins/workspace/swift_oss/swift-package-index-metrics@4/spi-workdir/D071710C-D745-481C-B50A-068827E39F1C/sentry-cocoa/.build-swiftbuild/arm64-apple-macosx/Products/Debug/Sentry.framework.dSYM' inf ``` ### Expected behavior Builds ### Actual behavior Fails to build ### Steps to reproduce ``` git clone https://github.com/getsentry/sentry-cocoa.git swift build --build-system=swiftbuild ``` ### Swift Package Manager version/commit hash _No response_ ### Swift & OS version (output of `swift --version ; uname -a`) _No response_

github.com/swiftlang/swift-build

Fix XCFramework output path conflicts for same-named libraries (#993)

main ← pepicrft:fix-xcframework-same-library-conflict

opened 08:36AM - 20 Dec 25 UTC

pepicrft

+201 -114

Fixes https://github.com/swiftlang/swift-package-manager/issues/9157 This cha…nge addresses an issue where multiple XCFrameworks containing libraries with the same name would cause build failures. When building a project that uses packages like Sentry.xcframework and Sentry-Dynamic.xcframework, both containing Sentry.framework internally, the build system would produce "Multiple commands produce" errors because they were all outputting to the same path in the build directory. The fix modifies the output directory computation to include the xcframework name as a subdirectory. This ensures each xcframework outputs to its own isolated location. For example, Sentry.xcframework now outputs to `build/Debug/Sentry/Sentry.framework` while Sentry-Dynamic.xcframework outputs to `build/Debug/Sentry-Dynamic/Sentry.framework`. This is a minimal change that resolves the conflict without affecting the existing linking and embedding behavior. > [!NOTE] > **Backward Compatibility Consideration** > > This change modifies the output directory structure for all XCFrameworks, not just those with conflicting library names. Projects with scripts, caches, or tooling that depend on the previous output paths (e.g., `build/Debug/Sentry.framework` instead of `build/Debug/Sentry/Sentry.framework`) may need updates. > > Is this acceptable, or should we consider an alternative approach that only adds the subdirectory when there's an actual conflict? The current approach is simpler and provides consistent, predictable output paths.

owenv · March 25, 2026, 2:32pm

The new backend does include support for xcframeworks - could you please file an issue with more detail about the failure you’re hitting, including steps to reproduce if possible?

Sarunas · March 25, 2026, 6:22pm

Reproduced this way: xcframework and snippets error: Multiple commands produce · Issue #1242 · swiftlang/swift-build · GitHub

Our main repo doesn't directly has snippets, but hopefully the cause is the same.

owenv · March 25, 2026, 8:51pm

Thank you for the reduced example - this should be addressed with Do not attempt to embed xcframework contents in non-bundle product types by owenv · Pull Request #1244 · swiftlang/swift-build · GitHub

Sarunas · April 9, 2026, 9:48am

@owenv thanks!
--build-system swiftbuild works now! Switching from 6.3 to swift-DEVELOPMENT-SNAPSHOT-2026-04-01 reveals 2 new actor isolation errors and 3 compiler crashes.

We also have an Xcode project which has ~50 SPM dependencies; is there anything to test here? SPM is only used to checkout the source code in this case?

Could you please advise on XCFramework: Unknown library type with extension 'so' in library 'linux-aarch64' · Issue #1250 · swiftlang/swift-build · GitHub ?