build: consume single self-contained SentryObjC xcframework; drop Sentry.xcframework

[jamescrosswell]

Summary

Completes #5444: the .NET SDK now consumes a single self-contained SentryObjC-Dynamic.xcframework (the SentryObjC* surface with the engine baked in) and no longer ships Sentry.xcframework. Follow-up to #5450 (which removed all use of the classic Sentry* Obj-C API); this removes the last structural dependency on Sentry.framework.

We build the single framework from the modules/sentry-cocoa submodule (replacing the previous three thin xcodebuild archive frameworks with sentry-cocoa's own dynamic-variant packaging), instead of the three thin frameworks that dynamically linked each other.

Important

SentryCrash must be compiled with SENTRY_CRASH_MANAGED_RUNTIME=1 (a compile-time #ifdef that makes the signal / mach-exception monitors cooperate with the managed .NET/mono runtime). The generic release artifact isn't built with it — so we can't use the generic pre-built framework archive.

What changed

• scripts/build-sentry-cocoa.sh — builds the single self-contained SentryObjC-Dynamic.xcframework via sentry-cocoa's own pipeline (build-xcframework-sentryobjc.sh --variant dynamic), then re-slices it to the platforms we ship: Carthage/Build-ios (device + simulator) and Carthage/Build-maccatalyst, plus headers. The old bespoke 3-scheme archive + inter-framework linking + nested-Frameworks stripping is gone.
• scripts/sentry-cocoa.xcconfig (new) — injects GCC_PREPROCESSOR_DEFINITIONS = $(inherited) SENTRY_CRASH_MANAGED_RUNTIME=1 via XCODE_XCCONFIG_FILE, because cocoa's packaging scripts don't expose extra build settings. (Verified: the define reaches the SentryCrash C compilation.)
• Sentry.Bindings.Cocoa.csproj — one NativeReference (SentryObjC-Dynamic.xcframework) instead of three.
• buildTransitive/Sentry.Bindings.Cocoa.targets — Hot-Restart simulator-strip regex updated to the single framework name.

Validation (local, macOS + Xcode 26.6, cocoa 9.26.0)

• The built device-test app embeds only SentryObjC.framework (no Sentry.framework).
• SENTRY_CRASH_MANAGED_RUNTIME=1 confirmed on the SentryCrash C compilation.
• Bundled framework size (ios + mac catalyst): ~23 MB, comparable to previous.

Closes #5492
Closes #5444

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 74.88%. Comparing base (cf1e60c) to head (6d3b017).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5500      +/-   ##
==========================================
+ Coverage   74.73%   74.88%   +0.14%     
==========================================
  Files         513      513              
  Lines       18744    18659      -85     
  Branches     3666     3636      -30     
==========================================
- Hits        14009    13972      -37     
+ Misses       3863     3818      -45     
+ Partials      872      869       -3     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[sentry]

Bug: The build script hardcodes XCFramework slice directory names. This is fragile and will break the build if the sentry-cocoa dependency changes its naming convention in a future update.
_{Severity: MEDIUM}

Suggested Fix

Instead of hardcoding the slice directory names, the script should dynamically discover them from the filesystem after the sentry-cocoa framework is built. Alternatively, add explicit checks to verify that each required slice directory exists before calling xcodebuild, and provide a clear error message if a path is not found. This will make the build process more resilient to changes in the dependency.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: scripts/build-sentry-cocoa.sh#L68-L74

Potential issue: The build script `scripts/build-sentry-cocoa.sh` uses hardcoded paths
for XCFramework slices, such as `ios-arm64` and `ios-arm64_x86_64-simulator`, when
calling `xcodebuild`. The script does not validate that these specific slice directories
exist before using them. If a future update to the `sentry-cocoa` dependency changes its
slice naming convention (for example, to support new architectures), the hardcoded paths
will become invalid. This will cause the `xcodebuild` command to fail, breaking the
entire SDK build process. While this failure would be caught by CI, it introduces
fragility and maintenance debt, as dependency updates could unexpectedly block builds.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[jamescrosswell]

@philprime is this a realistic concern worth adding complexity for?

I'm guessing if you ever changed things around significantly, you'd probably give us a heads up... worst case, our bump to a new version of sentry-cocoa would fail and we'd discover things had moved around. So kind of thinking it's easier to react to than to anticipate and avoid in advance.