iOS: RNSentry SPEC CHECKSUM is machine-specific (absolute xcframework path in FRAMEWORK_SEARCH_PATHS) → Podfile.lock churn across devs/CI

[gimi-anders]

Environment

• @sentry/react-native: 8.19.0 (current latest)
• react-native: 0.85.3
• CocoaPods: 1.17.0
• Platform: macOS, bare React Native app (Podfile.lock committed to git)

Summary

Since the switch to consuming sentry-cocoa as a prebuilt xcframework by default (#6413), the RNSentry entry under SPEC CHECKSUMS: in Podfile.lock is machine-specific. Two developers (or a developer and CI) running pod install on the exact same @sentry/react-native version get different RNSentry checksums, so Podfile.lock flips back and forth on every install and can never be committed to a stable value.

Root cause

RNSentry.podspec points FRAMEWORK_SEARCH_PATHS at the absolute pod-install-time path of the cached xcframework:

• packages/core/scripts/sentry_utils.rb (ensure_sentry_xcframework):

  cache_root = ENV['SENTRY_XCFRAMEWORK_CACHE_DIR'] ||
               File.expand_path('~/Library/Caches/sentry-react-native/xcframeworks')

• packages/core/RNSentry.podspec:

  paths = slice_ids.map { |slice| %("#{File.join(sentry_xcframework_dir, slice)}") }
  acc["FRAMEWORK_SEARCH_PATHS[sdk=#{sdk}*]"] = (['$(inherited)'] + paths).join(' ')

The resulting pod_target_xcconfig / user_target_xcconfig therefore contains e.g.:

FRAMEWORK_SEARCH_PATHS[sdk=iphoneos*] = $(inherited) "/Users/<username>/Library/Caches/sentry-react-native/xcframeworks/9.19.1/Sentry.xcframework/ios-arm64_arm64e"

Because CocoaPods computes the pod's SPEC CHECKSUM over the evaluated podspec (including this xcconfig), the <username> component leaks into the checksum. Different home directory → different checksum. The podspec comment notes the path "is regenerated on every pod install, so it's not something anyone commits" — but the checksum derived from it is written into Podfile.lock, which apps do commit.

Reproduction

1. Install pods on machine A → note RNSentry: <hashA> in Podfile.lock.
2. Install pods on machine B (different $HOME), same @sentry/react-native version → RNSentry: <hashB>, hashA != hashB.
3. Committing either value means the other machine (and CI) re-changes it on the next pod install. Endless churn; no committable value.

Impact

• Podfile.lock is non-deterministic across developers and CI, producing spurious diffs on every pod install.
• Teams that gate CI on a clean/consistent Podfile.lock get repeated failures or auto-commit ping-pong.

This is the same class of problem as facebook/react-native#31193 ("FBReactNativeSpec pod checksum is not stable") — local absolute paths leaking into a committed pod checksum.

Workaround (works today)

Set SENTRY_XCFRAMEWORK_CACHE_DIR to a fixed, username-free absolute path in the Podfile so every machine and CI evaluate the same string:

ENV['SENTRY_XCFRAMEWORK_CACHE_DIR'] = '/tmp/sentry-react-native-xcframeworks'

Verified: with this set, the RNSentry checksum is identical and stable across repeated installs; without it, it reverts to the per-$HOME value.

Suggested fix

Keep the fast prebuilt-xcframework path, but stop the machine-specific absolute path from entering the checksummed spec attributes — e.g. reference a build-setting placeholder (like $(SENTRY_XCFRAMEWORK_DIR)/<slice>) in FRAMEWORK_SEARCH_PATHS and inject the real absolute path via a mechanism that isn't part of the podspec checksum (e.g. a generated .xcconfig/build setting written at install time). That yields a deterministic, committable Podfile.lock while preserving static linking.

[linear-code]

RN-714

[sentry-pierre]

I checked the podspec and sentry_utils.rb — the paths are exactly where you said they are. The absolute cache path is hard-coded into FRAMEWORK_SEARCH_PATHS via pod_target_xcconfig and user_target_xcconfig, so CocoaPods' checksum picks up the username from $HOME. The workaround (SENTRY_XCFRAMEWORK_CACHE_DIR) is valid until a fix lands. A maintainer can take it from here.