rr-mohammad-abdurraafay
**Environment** - Xcode 27 Beta 4 (Xcode 26.6 builds fine) - lottie-spm 4.6.0 - Multi-package workspace (several local SPM packages each depending on `lottie-spm`) **What happens** Build fails with: ``` Multiple commands produce '.../Rakuten.app/Frameworks/Lottie.framework' Multiple commands produce '.../Rakuten.app/Frameworks/Lottie.framework/Lottie' Unexpected duplicate tasks ``` The build log reveals two conflicting tasks: 1. **Copy** `SourcePackages/artifacts/lottie-spm/Lottie/Lottie.xcframework/ios-arm64_x86_64-simulator/Lottie.framework` → `Rakuten.app/Frameworks/Lottie.framework` 2. **MkDir / ProcessInfoPlistFile** for a `Lottiedynamic-product` target also writing to `PackageFrameworks/Lottie.framework` **Root cause** `lottie-spm`'s `Package.swift` defines the `Lottie` product as: ```swift products: [.library(name: "Lottie", targets: ["Lottie", "_LottieStub"])] ``` The `_LottieStub` target was added as a workaround for [apple/swift-package-manager#6069](https://github.com/apple/swift-package-manager/issues/6069) so the package appears in "Frameworks, Libraries, and Embedded Content". Xcode 27's new build system (SwiftBuild) now generates separate embed tasks for both the `Lottie` binary target and the `_LottieStub`-based dynamic product — both resolving to the same output path. **Workaround** None found yet. The `_LottieStub` workaround appears to be the trigger. The original SPM bug may be fixed in Xcode 27, making the stub unnecessary (and now harmful). **Request** Could the `_LottieStub` workaround be conditionally removed, or replaced with a solution compatible with Xcode 27's build system?