Skip to content

fix(ios): dedupe DotLottiePlayer.xcframework signature to fix Xcode 26 archive ("File exists") #66

Description

@corvut

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)

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions