Xcode 27 Beta 4 regression: "Multiple commands produce" error when a SwiftPM binary xcframework product is linked from both an app target and an embedded framework target

Question

Created 2w

Replies 4

Boosts 4

Participants 3

In Xcode 27 Beta 4 (27A5228h), building a project that has a SwiftPM binary target (xcframework) linked directly from both an app target AND a framework target that is embedded in that app fails with "Multiple commands produce" errors. The same project and pbxproj builds successfully in Xcode 27 Beta 3 (27A5218g), so this is a regression introduced in Beta 4.

Steps to Reproduce

Create a new iOS App project.
Add a Framework target (e.g. "SampleCommon") and embed it into the app.
Add a SwiftPM dependency for a package that vends a binary xcframework product. Confirmed with airbnb/lottie-spm 4.6.1 (https://github.com/airbnb/lottie-spm).
In "Frameworks, Libraries, and Embedded Content" of the app target, add the SwiftPM product (Lottie) with "Embed & Sign".
In "Frameworks and Libraries" of the framework target, add the same SwiftPM product (Lottie).
Build the app scheme for iOS Simulator.

Expected result

Build succeeds. The xcframework is embedded exactly once into the .app bundle. This is the behavior in Xcode 27 Beta 3 and Xcode 26.

Actual result

Build fails with:

error: Unexpected duplicate tasks
error: Multiple commands produce '.../<App>.app/Frameworks/Lottie.framework/Lottie'
error: Multiple commands produce '.../<App>.app/Frameworks/Lottie.framework'

Two Copy tasks are emitted for the same output path in the app target:

Copy from Build/Products/Debug-iphonesimulator/PackageFrameworks/Lottie.framework
Copy from SourcePackages/artifacts/lottie-spm/Lottie/Lottie.xcframework/ios-arm64_x86_64-simulator/Lottie.framework

Additionally, an auto-generated target named "Lottiedynamic-product" emits duplicate MkDir / ProcessInfoPlistFile tasks for PackageFrameworks/Lottie.framework, which suggests the packaging path for binary xcframework products has been duplicated in Beta 4.

Regression

Xcode 27 Beta 3 (27A5218g): builds successfully
Xcode 27 Beta 4 (27A5228h): fails with the above errors
Xcode 26.x: builds successfully

Minimal reproduction

The issue reproduces on a 2-target Xcode project (app + framework) with airbnb/lottie-spm added and linked from both targetstory captures the smallest triggering diff:

pattern1: app links Lottie only -> BUILD SUCCEEDED
pattern2: framework links Lottie only -> BUILD SUCCEEDED
pattern3: both app and framework link Lottie -> BUILD FAILED (only on Beta 4)

Only the framework target's packageProductDependencies and Frameworks build phase entries differ between the succeeding and failing states.

Workaround

Link the SwiftPM binary product from only one target (either the app or the framework, not both). If only the framework tarl gets the framework transitively at runtime.

Impact

Any project that uses a SwiftPM binary xcframework and organizes code across multiple linked targets (a very common pattern for larger apps) is blocked from adopting Xcode 27 Beta 4.

Environment

Xcode 27.0 Beta 4 (27A5228h)
macOS 26.5.2
Package: airbnb/lottie-spm 4.6.1
Destination: iOS Simulator (iPhone 17, latest)

Answer 1

masaichi OP

2w

I also submitted feedback FB23932975.

Answer 2

coffee OP

17h

Also encountering this exact issue in Xcode 27 beta 5 as well. Submitted FB24273615.

Answer 3

DTS Engineer OP

Apple

15h

Thanks you for providing the bugs and the description of the issue as well as moving to Xcode 27 beta 5 to make sure the issue still there.

Bugs have been routed to the correct team.

You can see the status of your feedback in Feedback Assistant. There, you can track if the report is still being investigated, has a potential identifiable fix, or has been resolved in another way. The status appears beside the label "Resolution." We're unable to share any updates on specific reports on the forums.

For more details on when you'll see updates to your report, please see What to expect after submission.

The only workaround on top of my head is managing the .xcframework manually to bypass the SPM task generation? With removing the package dependency from your Xcode project and drag the .xcframework into your project navigator. Link it to both your App and Framework targets. Set it to Embed & Sign in the App target and Do Not Embed in the Framework target.

Not the intended way but is the only workaround but the way to bypass the SPM task generation?

Albert  WWDR

Answer 4

masaichi OP

2h

Thank you, Albert! Appreciate you routing the bugs to the right team, and thanks for the explanation on tracking the status in Feedback Assistant.

Thanks as well for the .xcframework suggestion. We'd rather keep our current SPM setup and wait for a fix in a subsequent beta than restructure the project around manually managed binaries, but it's good to know there's a way out if we need one.

One data point that may help narrow things down: Lottie ships a dedicated dynamic product (.library(name: "Lottie-Dynamic", type: .dynamic, targets: ["Lottie"])), and switching our dependency to that product avoids the issue. The package dependency stays in place there — SPM still generates its build tasks, and the only thing that changes is the linkage (static → dynamic). That makes me suspect the problem is specific to a static library being linked into multiple targets, rather than SPM task generation in general. Happy to add this to the report if it would help.

We'll keep re-testing with each beta. Thanks again for your time.