iOS archive fails on Xcode 26: “RaTeX.xcframework-ios.signature” (0.7.x, math enabled)

[lisabaut]

Issue

iOS archive fails on Xcode 26: “RaTeX.xcframework-ios.signature” couldn’t be copied to “Signatures” because an item with the same name already exists (0.7.x, math enabled)

Environment

• react-native-enriched-markdown: 0.7.2 (0.7.0 ships the identical RaTeX integration and is presumably affected — see “Secondary observation” for what we hit there)
• react-native: 0.85.3, Expo SDK 56 (CNG/prebuild), static linkage (default, no use_frameworks!)
• Xcode 26.4 (17E202) — EAS Build image macos-tahoe-26.4-xcode-26.4
• Fails on xcodebuild archive (device builds / EAS / Organizer). xcodebuild build (simulator, run:ios, Release device installs) is unaffected.

Summary

Since 0.7.0, math rendering pulls in the RaTeX XCFramework as a Swift Package via React Native’s spm_dependency. Compilation and linking succeed — even with static linkage — but archiving fails during archive assembly:

xcodebuild: error: “RaTeX.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

Xcode runs SignatureCollection for the RaTeX XCFramework twice — once for the RaTeX SPM product target and once for the ReactNativeEnrichedMarkdown pod target — producing two files with the same basename in different build-products directories:

Release-iphoneos/RaTeX.xcframework-ios.signature
Release-iphoneos/ReactNativeEnrichedMarkdown/RaTeX.xcframework-ios.signature

During archive assembly, Xcode copies all collected signatures into the flat <archive>/Signatures/ directory, and the second copy collides with the first.

This is a known Xcode 26 failure class for signed binary XCFrameworks consumed via SPM alongside CocoaPods. Prior art:

• dotlottie-react-native fixed the identical bug with a podspec script phase: fix(ios): dedupe DotLottiePlayer.xcframework signature to fix Xcode 26 archive ("File exists") LottieFiles/dotlottie-react-native#66
• maplibre-react-native hit it on Xcode 26.4: Bare RN Build Archive Xcode 26.4: “MapLibre.xcframework-ios.signature” couldn’t be copied to “Signatures” because an item with the same name already exists maplibre/maplibre-react-native#1489

Suggested fix

Same approach as dotlottie: delete the pod-target copy after compile, e.g. appended to the existing Fix RaTeXFFI Module Redefinition script phase in ReactNativeEnrichedMarkdown.podspec (it is a no-op when the file doesn’t exist, so it’s safe on older Xcode versions and simulator builds):

rm -rf "${CONFIGURATION_BUILD_DIR}/RaTeX.xcframework-ios.signature"

Alternatively, vendoring RaTeX as an XCFramework pod dependency instead of spm_dependency would eliminate this entire class of SPM/CocoaPods interop issues (see also “Secondary observation” below).

Workaround for affected users (verified)

Expo users can apply the dedupe app-side with a config plugin that injects the same rm into the Podfile’s post_install as a build phase on the ReactNativeEnrichedMarkdown target:

post_install do |installer|
  installer.pods_project.targets.each do |target|
    next unless target.name == 'ReactNativeEnrichedMarkdown'
    phase = target.new_shell_script_build_phase('Dedupe RaTeX XCFramework Signature')
    phase.shell_script = 'rm -rf "${CONFIGURATION_BUILD_DIR}/RaTeX.xcframework-ios.signature"'
    phase.always_out_of_date = '1'
  end
end

Secondary observation (transient)

On our first 0.7.0 archive attempt on the same Xcode 26.4 image, xcodebuild -resolvePackageDependencies (and the subsequent archive) crashed while loading the Pods project containing the CocoaPods-written XCRemoteSwiftPackageReference:

-[XCRemoteSwiftPackageReference _setSavedArchiveVersion:]: unrecognized selector sent to instance
Exception: … The project ‘Pods’ is damaged and cannot be opened.

xcodebuild then silently proceeded without the Pods project (target dependency graph collapsed from 155 to 2 targets), so every pod modulemap was missing and the build failed with no such module 'Expo'. This did not reproduce on the next build (0.7.2 — identical podspec/SPM integration), so it appears non-deterministic — but it’s a second data point that the SPM-package-inside-Pods-project setup is fragile on current Xcode, and another argument for the vendored-XCFramework route.

Reproduction

1. Expo SDK 56 app, react-native-enriched-markdown 0.7.x, math enabled (default), static linkage (default).
2. eas build --platform ios with any device profile (or archive in Xcode/Organizer) on Xcode 26.4.
3. Build compiles and links, then fails at archive assembly with the signature collision above.

[hryhoriiK97]

Hi @lisabaut, thank you for the detailed investigation and issue. I've already opened a PR and I'm going to make the 0.7.3 release with this fix.

[hryhoriiK97]

@lisabaut I've released 0.7.3 with the fix - please let me know if this solves the problem on your side

[shamilovtim]

Still have the same bug, even with OP's workaround. The bug I have is in regular debug simulator builds, not archives.

error: redefinition of module 'RaTeXFFI'

The fix I found was the following in Podfile:

    installer.pods_project.targets.each do |target|
      next unless target.name == 'ReactNativeEnrichedMarkdown'

      target.build_configurations.each do |config|
        # Xcode 26's Swift scanner sees RaTeXFFI before this pod's cleanup script removes the duplicate modulemap.
        config.build_settings['CLANG_ENABLE_EXPLICIT_MODULES'] = 'NO'
        config.build_settings['SWIFT_ENABLE_EXPLICIT_MODULES'] = 'NO'
      end
    end

[hryhoriiK97]

@shamilovtim Thanks for reporting. The "Fix RaTeXFFI Module Redefinition" script phase we ship should handle this - it strips the duplicate modulemap entry before compile.

However, it sounds like Xcode 26's explicit modules scanner may pre-evaluate the module graph before the script phase runs, making the sed fix ineffective in your setup.

I've tried to reproduce this on both Xcode 26.1 and 26.5 but everything works as expected on my end - the script phase resolves the redefinition without needing to disable explicit modules.

Could you share:

1. Exact Xcode version?
2. CocoaPods version?
3. Are you using Expo CNG/prebuild or bare RN?
4. Does the issue reproduce on a fresh pod install?

Your workaround of disabling explicit modules on the ReactNativeEnrichedMarkdown target is safe in the meantime.

[lisabaut]

@hryhoriiK97 Thanks for the quick fix!
Confirming 0.7.3 resolves the original archive failure for us — device archive on EAS (Xcode 26.4) succeeds, and we were able to remove our config-plugin workaround. 🙏

[shamilovtim]

Hi thanks for reviewing. We compile with Fastlane, Bare Workflow with Expo (no prebuild). We build from source and don't use precompiled RN. Here are all of our versions:

  expo-env-info 2.1.0 environment info:
    System:
      OS: macOS 26.5.2
      Shell: 3.5.1 - /usr/local/bin/fish
    Binaries:
      Node: 22.22.2 - /Users/admin/.local/share/mise/installs/node/22.22.2/bin/node
      npm: 10.9.7 - /Users/admin/.local/share/mise/installs/node/22.22.2/bin/npm
      Watchman: 2026.01.12.00 - /opt/homebrew/bin/watchman
    Managers:
      CocoaPods: 1.16.2 - /Users/admin/.local/share/mise/installs/ruby/3.4.8/bin/pod
    SDKs:
      iOS SDK:
        Platforms: DriverKit 25.5, iOS 26.5, macOS 26.5, tvOS 26.5, visionOS 26.5, watchOS 26.5
      Android SDK:
        API Levels: 34, 35, 36
        Build Tools: 34.0.0, 35.0.0, 36.0.0
        System Images: android-35 | Google Play ARM 64 v8a
    IDEs:
      Android Studio: 2026.1 AI-261.23567.138.2611.15503007
      Xcode: 26.6/17F113 - /usr/bin/xcodebuild
    npmPackages:
      babel-preset-expo: ^57.0.1 => 57.0.1
      expo: ^57.0.2 => 57.0.2
      react: 19.2.3 => 19.2.3
      react-dom: 19.2.3 => 19.2.3
      react-native: 0.86.0 => 0.86.0
    Expo Workflow: bare

Sadly I am getting completely separate archive errors from this RaTeX as well, not just the Simulator debug build errors. See the following, there are several different ones, and if I fix one error, the other ones continue.

1. RaTeX is messing with our signing. We already have a development team for our app. I doesn't like that we're using manual signing, and it's not inheriting the manual signing profile. I tried passing a manual development team as a workaround.

[00:44:51]: ▸ ❌  SourcePackages/checkouts/RaTeX/Package.swift: Signing for "RaTeX_RaTeX" requires a development team. Select a development team in the Signing & Capabilities editor. (in target 'RaTeX_RaTeX' from project 'RaTeX')

2. RaTeX again started complaining about our signing, demanding we use Automatic signing:

[09:44:26]: ▸ ❌ SourcePackages/checkouts/RaTeX/Package.swift: RaTeX_RaTeX has conflicting provisioning settings. RaTeX_RaTeX is automatically signed, but provisioning profile match AppStore Foo has been manually specified. Set the provisioning profile value to "Automatic" in the build settings editor, or switch to manual signing in the Signing & Capabilities editor. (in target 'RaTeX_RaTeX' from project 'RaTeX')

I am also concerned that this RaTeX package is cloned from Github in real time which is a safety issue. It's adding noticeable build time in the output you see where it's spending a significant amount of time cloning this package, building it, signing it, etc. I will downgrade to the ~v0.6 version for now.

[davidbaloghOTP]

Hi, the issue still persists for iOS Simulator Archives. I am on version 0.7.4
The following post-install workaround is still needed:

installer.pods_project.targets.each do |target|
  next unless target.name == 'ReactNativeEnrichedMarkdown'

  phase = target.new_shell_script_build_phase(
    'Dedupe RaTeX XCFramework Signature'
  )

  phase.shell_script = 'rm -rf "${CONFIGURATION_BUILD_DIR}/RaTeX.xcframework-ios-simulator.signature"'
  phase.always_out_of_date = '1'
end

[shamilovtim]

Yeah, I also mentioned it previously as well. I am permanently stuck on the 0.6.x line of this package until the RaTeX stuff is fixed. I can't archive a regular arm64 release due to all of the build errors. I'm on the latest expo and react native.

[eszlamczyk]

Hi @davidbaloghOTP @shamilovtim @lisabaut — we've moved iOS RaTeX off spm_dependency to a vendored prebuilt static XCFramework (#652). Because a single target now processes a single XCFramework, only one signature is produced, so the archive collision is gone, including the RaTeX.xcframework-ios-simulator.signature variant the earlier rm workaround missed. It also drops the forced use_frameworks! :linkage => :dynamic, the build-time RaTeX clone/Rust build, and the RaTeX_RaTeX signing prompts - math now links under CocoaPods default static linkage with no Podfile changes.

This should be in today's nightly release. You should be able to drop the manual post-install workarounds. If you can give it a try, we'd love to hear whether it fixes things for you. 🙏