WIP: feat(ios): opt-in consumption of sentry-cocoa via Swift Package Manager#6182
WIP: feat(ios): opt-in consumption of sentry-cocoa via Swift Package Manager#6182alwx wants to merge 1 commit into
Conversation
Adds a new opt-in path in RNSentry.podspec: when `SENTRY_USE_SPM=1` is set in the environment before `pod install`, RNSentry pulls `Sentry` from the sentry-cocoa SPM package (as a binary xcframework) instead of from the Sentry CocoaPods source build. Default behavior is unchanged. Existing users on any React Native version keep their current CocoaPods-based consumption with no action required. The opt-in path requires React Native >= 0.75 because it uses the `SPMManager` singleton defined in `react-native/scripts/cocoapods/spm.rb`, which is loaded transitively from the Podfile via `react_native_pods.rb`. This is the first step of the broader SPM migration tracked at #5780. It unblocks experimentation with binary-framework consumption of sentry-cocoa while keeping CocoaPods as the production default. Two known caveats for users opting in today: 1. The Sentry xcframework in sentry-cocoa 9.13.0 and earlier is missing the `SentrySessionReplayHybridSDK` symbol due to a packaging bug (getsentry/sentry-cocoa#7911). Apps that use Session Replay will fail to link until that fix ships in a sentry-cocoa release. Apps not using Session Replay are unaffected. 2. `SentrySwizzle.h` must be imported via framework-style (`<Sentry/...>`) rather than quote-style when the xcframework is the consumption path — already handled by #6175 (in this same release). Verified locally: - Default `pod install` (no env var) — `** BUILD SUCCEEDED **` on the RN sample, identical to the pre-change state. - `SENTRY_USE_SPM=1 pod install` — Sentry no longer in Podfile.lock, `XCRemoteSwiftPackageReference "sentry-cocoa"` injected into the Xcode project, [SPM] log lines confirm the helper ran correctly. Refs: #5780, #6170
Semver Impact of This PR⚪ None (no version bump detected) 📋 Changelog PreviewThis is how your changes will appear in the changelog.
Plus 7 more 🤖 This preview updates automatically when you update the PR. |
Instructions and example for changelogPlease add an entry to Example: ## Unreleased
### Features
- opt-in consumption of sentry-cocoa via Swift Package Manager ([#6182](https://github.com/getsentry/sentry-react-native/pull/6182))If none of the above apply, you can opt out of this check by adding |
![sentry-warden[bot]](https://avatars.githubusercontent.com/in/2755838?s=60&v=4){kind=small}
| 'This requires React Native >= 0.75 and a Podfile that imports ' \ | ||
| 'react_native_pods.rb.' | ||
| end | ||
| SPM.dependency(s, | ||
| url: 'https://github.com/getsentry/sentry-cocoa', | ||
| requirement: { kind: 'exactVersion', version: '9.13.0' }, |
There was a problem hiding this comment.
SPM path pins version 9.13.0 which is missing SentrySessionReplayHybridSDK, causing a linker failure for any app using Session Replay
The SentrySessionReplayHybridSDK symbol—actively referenced in RNSentryReplayBreadcrumbConverter.m—is absent from the sentry-cocoa 9.13.0 xcframework (getsentry/sentry-cocoa#7911). Any project that sets SENTRY_USE_SPM=1 and has Session Replay enabled will fail to link, with no code-level warning surfaced at pod install time. Consider either raising an explicit error when SENTRY_USE_SPM=1 is set (pointing users to wait for the fixed release) or documenting the minimum fixed version in the guard so the pin is updated atomically when the cocoa fix ships.
Verification
Confirmed SentrySessionReplayHybridSDK is called in packages/core/ios/RNSentryReplayBreadcrumbConverter.m (lines 14, 43, 75, 95, 183). The SPM path pins exactVersion: '9.13.0', which the PR body explicitly identifies as having the packaging bug. The CocoaPods path (source build) is unaffected because it compiles from source. No runtime or pod-install-time guard exists in the new code block to catch this for SPM consumers.
Identified by Warden code-review · MTW-NU4
1 participant
Adds a new opt-in path in RNSentry.podspec: when
SENTRY_USE_SPM=1is set in the environment beforepod install, RNSentry pullsSentryfrom the sentry-cocoa SPM package (as a binary xcframework) instead of from the Sentry CocoaPods source build.This is the first step of the broader SPM migration tracked at #5780. It unblocks experimentation with binary-framework consumption of sentry-cocoa while keeping CocoaPods as the production default.
BUT those things need to be done before we will be able to migrate:
SentrySessionReplayHybridSDKsymbol due to a packaging bug (fix(replay): correct file type for SentrySessionReplayHybridSDK.m in pbxproj sentry-cocoa#7911). Apps that use Session Replay will fail to link until that fix ships in a sentry-cocoa release. Apps not using Session Replay are unaffected.SentrySwizzle.hmust be imported via framework-style (<Sentry/...>) rather than quote-style when the xcframework is the consumption path — already handled by #6181Verified locally:
pod install(no env var) —** BUILD SUCCEEDED **on the RN sample, identical to the pre-change state.SENTRY_USE_SPM=1 pod install— Sentry no longer in Podfile.lock,XCRemoteSwiftPackageReference "sentry-cocoa"injected into the Xcode project, [SPM] log lines confirm the helper ran correctly.Refs: #5780, #6170
📢 Type of change
📜 Description
💡 Motivation and Context
💚 How did you test it?
📝 Checklist
sendDefaultPIIis enabled🔮 Next steps