fix(ios): remove duplicate Sentry.xcframework signature to unblock Xcode 26 archive

[airowe]

Summary

Archiving an app that integrates @frontegg/react-native with use_frameworks! under Xcode 26 fails deterministically:

"Sentry.xcframework-ios.signature" couldn't be copied to "Signatures"
because an item with the same name already exists. File exists
Exit status: 70

Fixes #108.

Root cause

FronteggSwift transitively links sentry-cocoa. With use_frameworks!, Sentry.xcframework ends up embedded/signed in two places, so Xcode 26's new xcframework signature-collection step tries to copy two files of the same name into the shared Signatures/ dir:

SignatureCollection .../Release-iphoneos/Sentry.xcframework-ios.signature
SignatureCollection .../Release-iphoneos/FronteggRN/Sentry.xcframework-ios.signature   <-- duplicate

This is the same multi-target xcframework-signature issue MapLibre RN hit — see maplibre-react-native#1489 / maplibre-react-native#1490.

Fix

Add a pod-target script_phase to FronteggRN.podspec that removes this pod's duplicate copy after it builds, before the app archive collects signatures:

s.script_phase = {
  :name => '[Frontegg] Remove duplicate Sentry.xcframework-ios.signature',
  :script => 'rm -rf "$CONFIGURATION_BUILD_DIR/Sentry.xcframework-ios.signature"',
  :execution_position => :after_compile
}

• The app-level copy is untouched, so Sentry stays signed.
• It's a harmless no-op when Sentry isn't present or on pre-Xcode-26 toolchains.
• Placing it in the podspec (rather than a consumer post_install) means it applies automatically on both the modern spm_dependency path and the frontegg_spm.rb fallback — no Podfile changes for consumers.
• Mirrors the mechanism in maplibre-react-native#1490 (they attach the equivalent phase from their own SPM helper).

Verification

The signature-removal itself is verified: applying the identical rm -rf "$CONFIGURATION_BUILD_DIR/Sentry.xcframework-ios.signature" on the app targets (via post_install) takes the archive from the error above to ** ARCHIVE SUCCEEDED ** on Xcode 26.1.1 and 26.3, in a large multi-target (white-label) RN workspace with use_frameworks!.

This PR moves that same removal into the podspec on the FronteggRN pod target. The collision is a name clash between two identical-named signature files, so removing either copy resolves it; I've confirmed the app-level removal by archive and reasoned the pod-level removal is symmetric (the pod emits its copy before the app's collection step). It would be great to confirm on the example app in CI — happy to iterate on placement (:after_compile vs :before_compile) if your CI shows a timing preference.

Environment

@frontegg/react-native 1.2.20 · FronteggSwift 1.3.13 (SPM) · sentry-cocoa 8.58.4 · use_frameworks! · CocoaPods 1.16.2 · Xcode 26.1.1 / 26.3 · React Native, multi-target workspace.

[dianaKhortiuk-frontegg]

Approving — the mechanism checks out and both E2E checks are green.

The script_phase removes only the pod's duplicate Sentry.xcframework-ios.signature after compile, leaving the app-level copy signed, and it's a no-op when Sentry isn't linked or on pre-Xcode-26 toolchains. Mirrors maplibre-react-native#1490.

One caveat recorded for follow-up rather than blocking: our CI cannot actually verify this fix. The iOS E2E workflow runs build-for-testing, not archive (react-native-sdk-e2e.yml:189), and this fixes an archive failure — so the green checks don't exercise the code path in question. Merging on the strength of your local verification on 26.1.1 / 26.3 plus the low blast radius (worst case the rm -rf is a no-op). I'll file a separate ticket to add an archive step to CI so this is covered going forward.

Thanks for the clear write-up on #108 — the duplicate-signature diagnosis made this easy to follow.