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 7

Boosts 4

Participants 4

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

1d

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

Answer 3

DTS Engineer OP

Apple

1d

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

1d

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.

Answer 5

DTS Engineer OP

Apple

1d

Thanks for your reply.

By confirming that switching to the dynamic product (Lottie-Dynamic) resolves the issue while keeping the SPM dependency and build tasks intact, you have effectively isolated the root cause. It strongly indicates that the issue is indeed with how the static library is being linked across multiple targets.

Please may I ask you to add that information on your bug filed as this detail will save the engineering team a lot of time in their investigation.

Thanks again!

Albert  WWDR

Answer 6

Prasann1202 OP

16h

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

Workaround to make some frameworks dynamic, one of the example frameworks was Sentry. Luckily they have Sentry-dynamic so it was easy switch, but for others we have a workaround with

products: [
        .library(
            name: "SocureDoc",
            type: .dynamic,
            targets: ["SocureDoc"])
    ],

Answer 7

masaichi OP

14h

Hi Albert,

Thanks — I've added the details to the report, but I need to correct my previous message before the engineering team acts on it. My earlier comparison was incomplete, and the follow-up testing points somewhere narrower than "static linkage."

The issue: Lottie-Dynamic isn't offered by the package our report actually uses. Our setup depends on the Lottie product from lottie-spm, which doesn't build from source at all — it declares a binaryTarget pointing at a precompiled Lottie.xcframework.zip from a lottie-ios release (statically linked, as I confirmed locally). Lottie-Dynamic is declared in the separate source package, lottie-ios. So switching to it changed both the linkage and the distribution form.

I've since tested the plain Lottie product from lottie-ios as well — static, but built from source:

Package Product Form Result lottie-spm Lottie prebuilt static XCFramework via binaryTarget fails lottie-ios Lottie static, built from source succeeds lottie-ios Lottie-Dynamic dynamic, built from source succeeds

Since the source-built static product builds fine, static linkage across multiple targets isn't sufficient to trigger this. What reproduces it is a prebuilt static XCFramework distributed via a binaryTarget and linked into more than one target — which also fits with the manual .xcframework route being the workaround you suggested.

Apologies for the detour with the earlier conclusion. Everything above is now in the report, and I'll keep re-testing with each beta.

Thanks again for your help.