fix(ios): Cache xcframework in ~/Library/Caches, not inside node_modules

Repro on a bare RN app installed via `pnpm install
--config.node-linker=isolated` (pnpm's strict store makes package
directories read-only): pod install failed with

    Permission denied @ dir_s_mkdir - .../node_modules/.pnpm/
    @sentry+react-native.../ios/Vendor

Under pnpm's isolated store (and Yarn PnP), the SDK package directory
is either a read-only symlink into a shared store or not materialized
on disk at all — writing our xcframework cache there is not portable.
Move the cache to `~/Library/Caches/sentry-react-native/xcframeworks/
<version>/` (macOS user cache, always writable, deduped across
projects on the same machine). Override with `SENTRY_XCFRAMEWORK_CACHE_DIR`
for CI or enterprise setups.

Also drop `s.vendored_frameworks = 'ios/Vendor/Sentry.xcframework'`.
It was decorative — CocoaPods doesn't stage vendored xcframeworks for
`path:` (development) pods, which is why we already had to wire
FRAMEWORK_SEARCH_PATHS manually. Linking still happens: clang's
`-fmodules-autolink` (default) emits the `-framework Sentry`
directive as soon as `@import Sentry;` in RNSentry.mm resolves the
module through the search paths. With the vendored_frameworks entry
gone, the podspec no longer points at a path that only existed inside
node_modules.

Verified locally against a bare RN 0.86 sample installed via pnpm
strict + chmod a-w on the package's ios/ directory: pod install
succeeds, build succeeds, app boots, native crash → dSYM upload path
still works.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

Author: alwx

.gitignore

@@ -91,9 +91,6 @@ node_modules.bak
 # API Extractor temp files
 /packages/core/temp/
 
-# sentry-cocoa xcframework downloaded at pod install time
-/packages/core/ios/Vendor/
-
 # Sentry React Native Monorepo
 /packages/core/README.md
 .env.sentry-build-plugin

packages/core/RNSentry.podspec

@@ -63,7 +63,6 @@ Pod::Spec.new do |s|
   else
     s.source_files = 'ios/**/*.{h,m,mm}', 'cpp/**/*.{h,cpp}'
   end
-  s.exclude_files = 'ios/Vendor/**/*'
   s.public_header_files = 'ios/RNSentry.h', 'ios/RNSentrySDK.h', 'ios/RNSentryStart.h', 'ios/RNSentryVersion.h', 'ios/RNSentryBreadcrumb.h', 'ios/RNSentryReplay.h', 'ios/RNSentryReplayBreadcrumbConverter.h', 'ios/Replay/RNSentryReplayMask.h', 'ios/Replay/RNSentryReplayUnmask.h', 'ios/RNSentryTimeToDisplay.h'
 
   s.compiler_flags = other_cflags
@@ -77,12 +76,14 @@ Pod::Spec.new do |s|
   # Consume sentry-cocoa as a prebuilt `Sentry.xcframework` by default.
   #
   # The xcframework is downloaded from sentry-cocoa's GitHub Release,
-  # SHA256-verified, and cached under `ios/Vendor/`. CocoaPods then links it
-  # via `s.vendored_frameworks`. This avoids compiling sentry-cocoa from
-  # source (fast install) and sidesteps the Xcode 16/26 archive bug that
-  # affects the same xcframework when consumed through Xcode's SPM
-  # integration (`Signatures/*.signature` collision during archive) — the
-  # CocoaPods embed path is a different pipeline and is not affected.
+  # SHA256-verified, and cached under `~/Library/Caches/sentry-react-native/
+  # xcframeworks/<version>/` (override with `SENTRY_XCFRAMEWORK_CACHE_DIR`).
+  # Slice paths are then wired into the pod and app target via
+  # `FRAMEWORK_SEARCH_PATHS` below. Consuming the xcframework this way
+  # avoids compiling sentry-cocoa from source (fast install) and
+  # sidesteps the Xcode 16/26 archive bug that affects the same
+  # xcframework when consumed through Xcode's SPM integration
+  # (`Signatures/*.signature` collision during archive).
   #
   # Set `SENTRY_USE_XCFRAMEWORK=0` to fall back to the source-built
   # `Sentry` CocoaPod (e.g. for offline builds behind a restrictive proxy).
@@ -102,7 +103,19 @@ Pod::Spec.new do |s|
 
   if use_xcframework
     sentry_xcframework_dir = ensure_sentry_xcframework(sentry_cocoa_version, 'Sentry')
-    s.vendored_frameworks = 'ios/Vendor/Sentry.xcframework'
+
+    # We deliberately do NOT set `s.vendored_frameworks` even though the
+    # xcframework is downloaded and referenced below. CocoaPods doesn't
+    # stage vendored xcframeworks for `path:` (development) pods anyway
+    # — it did nothing for us functionally — and pointing it at a path
+    # inside `node_modules/@sentry/react-native/ios/Vendor/` used to be
+    # actively harmful, because that path only existed when the SDK was
+    # cached into the package directory (broken under pnpm's isolated
+    # store / Yarn PnP where node_modules is read-only). Framework
+    # linking still happens: `@import Sentry;` in RNSentry.mm + user
+    # code triggers clang's `-fmodules-autolink`, which emits the
+    # `-framework Sentry` linker directive automatically once the
+    # module is discovered via `FRAMEWORK_SEARCH_PATHS` below.
 
     # Xcode's `-F <dir>` doesn't descend into `.xcframework` bundles — it
     # looks for `Sentry.framework` directly at the given path. Point a

packages/core/scripts/sentry_utils.rb

@@ -83,18 +83,30 @@ def is_new_hermes_runtime(rn_version)
   'xrsimulator'      => %w[xros-arm64_x86_64-simulator],
 }.freeze
 
-# Ensures `<sdk_root>/ios/Vendor/<product>.xcframework` exists.
+# Ensures `<cache>/<version>/<product>.xcframework` exists.
 #
 # On first invocation, downloads the prebuilt xcframework zip from
 # sentry-cocoa's GitHub release, verifies its SHA256 checksum against
 # `SENTRY_COCOA_XCFRAMEWORK_CHECKSUMS`, and extracts it. Subsequent
-# invocations are no-ops.
+# invocations are no-ops. Returns the absolute path to the extracted
+# xcframework, which callers pass to `FRAMEWORK_SEARCH_PATHS`.
+#
+# The cache lives under a user-writable directory (`~/Library/Caches/
+# sentry-react-native/xcframeworks/` on macOS by default; override with
+# `SENTRY_XCFRAMEWORK_CACHE_DIR`). Cannot live under the pod's own source
+# tree because pnpm's isolated store makes `node_modules/@sentry/
+# react-native/ios/` read-only, and `Yarn PnP` doesn't materialize the
+# package directory at all — writing there fails with `EACCES`.
+# Deduplicating cache across multiple RN projects on the same machine
+# is a nice side effect.
 #
 # Consuming sentry-cocoa this way (vs. through Xcode's SPM integration)
 # avoids the Xcode 16/26 archive bug where a signed SPM binary xcframework's
 # `Signatures/*.signature` file collides during the archive step.
 def ensure_sentry_xcframework(version, product = 'Sentry')
-  vendor_dir = File.expand_path('../ios/Vendor', __dir__)
+  cache_root = ENV['SENTRY_XCFRAMEWORK_CACHE_DIR'] ||
+               File.expand_path('~/Library/Caches/sentry-react-native/xcframeworks')
+  vendor_dir = File.join(cache_root, version)
   target_dir = File.join(vendor_dir, "#{product}.xcframework")
   # Treat the presence of `Info.plist` inside the xcframework as the "healthy"
   # sentinel rather than just the directory existence. A directory without