Problem
Archiving an app that depends on @lottiefiles/dotlottie-react-native fails on Xcode 26 at the archive assembly step (compilation, linking, code-signing and validation all succeed first):
xcodebuild: error: "DotLottiePlayer.xcframework-ios.signature" couldn't be copied
to "Signatures" because an item with the same name already exists.:
The operation couldn't be completed. File exists
Exit status: 70
Root cause
DotLottiePlayer.xcframework (vended by the DotLottie SwiftPM product we pull via spm_dependency) is processed twice in a single archive — once by the SwiftPM DotLottie target and once by the dotlottie-react-native pod target:
ProcessXCFramework .../SourcePackages/checkouts/dotlottie-ios/.../DotLottiePlayer.xcframework
-> .../Dev-Release-iphoneos/DotLottiePlayer.framework
ProcessXCFramework .../SourcePackages/checkouts/dotlottie-ios/.../DotLottiePlayer.xcframework
-> .../Dev-Release-iphoneos/dotlottie-react-native/DotLottiePlayer.framework
SignatureCollection .../Dev-Release-iphoneos/DotLottiePlayer.xcframework-ios.signature
SignatureCollection .../Dev-Release-iphoneos/dotlottie-react-native/DotLottiePlayer.xcframework-ios.signature
Since Xcode 16, archiving collects each embedded XCFramework’s signature into a single flat <archive>/Signatures/ folder. The two collected files share the same basename (DotLottiePlayer.xcframework-ios.signature), so the second copy collides → File exists → exit 70.
Fix
Add a pod-target script phase that drops this pod target’s duplicate signature after it’s produced; the top-level one is kept, so exactly one remains when the archive’s Signatures/ folder is assembled.
s.script_phase = {
:name => 'Remove duplicate DotLottiePlayer xcframework signature',
:script => 'rm -rf "${CONFIGURATION_BUILD_DIR}/DotLottiePlayer.xcframework-ios.signature"',
:execution_position => :after_compile
}
It’s a no-op when the signature isn’t produced (older Xcode), so it’s safe to ship unconditionally. This mirrors the fix maplibre-react-native shipped in their podspec for the identical error (maplibre/maplibre-react-native#1490).
Validation
- Repro: archive a RN 0.83 (New Architecture) app depending on
dotlottie-react-native@0.9.3 on Xcode 26 → exit 70.
- With this change:
xcodebuild … archive completes, the resulting .xcarchive/Signatures/ contains exactly one DotLottiePlayer.xcframework-ios.signature, and Products/Applications/<App>.app is present.
Environment
@lottiefiles/dotlottie-react-native 0.9.3 → dotlottie-ios 0.15.6 (DotLottie SwiftPM product)
- react-native 0.83.1 (Fabric / New Architecture), CocoaPods via
spm_dependency
- Reproduced on Xcode 26.2 (CI) and 26.5 (local)
Problem
Archiving an app that depends on
@lottiefiles/dotlottie-react-nativefails on Xcode 26 at the archive assembly step (compilation, linking, code-signing and validation all succeed first):Root cause
DotLottiePlayer.xcframework(vended by theDotLottieSwiftPM product we pull viaspm_dependency) is processed twice in a single archive — once by the SwiftPMDotLottietarget and once by thedotlottie-react-nativepod target:Since Xcode 16, archiving collects each embedded XCFramework’s signature into a single flat
<archive>/Signatures/folder. The two collected files share the same basename (DotLottiePlayer.xcframework-ios.signature), so the second copy collides →File exists→ exit 70.Fix
Add a pod-target script phase that drops this pod target’s duplicate signature after it’s produced; the top-level one is kept, so exactly one remains when the archive’s
Signatures/folder is assembled.It’s a no-op when the signature isn’t produced (older Xcode), so it’s safe to ship unconditionally. This mirrors the fix
maplibre-react-nativeshipped in their podspec for the identical error (maplibre/maplibre-react-native#1490).Validation
dotlottie-react-native@0.9.3on Xcode 26 → exit 70.xcodebuild … archivecompletes, the resulting.xcarchive/Signatures/contains exactly oneDotLottiePlayer.xcframework-ios.signature, andProducts/Applications/<App>.appis present.Environment
@lottiefiles/dotlottie-react-native0.9.3 →dotlottie-ios0.15.6 (DotLottieSwiftPM product)spm_dependency