ref: migrate Cocoa bindings from PrivateSentrySDKOnly to SentryObjCSDK.internal

[jamescrosswell]

Migrates the iOS / Mac Catalyst hybrid-SDK bindings off the deprecated PrivateSentrySDKOnly (static methods, slated for removal in the next sentry-cocoa major) to the structured SentryObjCSDK.internal API introduced in sentry-cocoa 9.19. main already pins sentry-cocoa 9.22.0, so no dependency bump is required.

Key incremental/separate commits, in case this helps for review purposes:

• Phase 1 — regenerate bindings against the SentryObjC headers (build-sentry-cocoa.sh, generate-cocoa-bindings.ps1, patch-cocoa-bindings.cs, ApiDefinitions.cs). PrivateSentrySDKOnly kept in parallel - e532a2f
• Phase 2 — migrate the 5 call sites and the SentryCocoaHybridSdk alias to the new instance-based API cada275
• Phase 3 — remove PrivateSentrySDKOnly from the binding, patch/generate scripts, and props 55ff0b8

Note: We build from source now

• The .NET-consumed surface is only 5 call sites, via the SentryCocoaHybridSdk MSBuild alias (SetSdkName, SetTrace, StartProfilerForTrace, CollectProfileBetween, IgnoreNextSignal). Every one has a direct equivalent within [SentryObjCSDK internal].
• ⚠️ The published SentryObjC-Dynamic.xcframework is not usable as-is. It is fully self-contained (~4.4 MB/slice): it defines SentryHubInternal, SentryClientInternal, SentryObjCSDK and the SentrySwift classes, and links no external Sentry.framework. Bundling it alongside the Sentry.framework we already ship would put two full copies of the SDK in the app, with split runtime state — the managed bindings would talk to one instance and the new internal calls to another.
• sentry-cocoa exposes a buildable SentryObjC Xcode scheme; it builds cleanly and ships the SentryObjCSDK / SentryObjCInternalApi public headers.
• ✅ Building SentryObjC + SentryObjCCompat from source produces thin two frameworks (136 KB + 1.2 MB) that only define the new additive SentryObjC* wrapper types and import the real SDK classes (_SentryScope, _SentryBreadcrumb, _SentryUser, …) as undefined symbols resolved at load time from the existing Sentry.framework via @rpath. No duplication; the new API shares the same SDK instance as the current bindings.

Issues

Closes #5331

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 74.58%. Comparing base (65c0c59) to head (1163b23).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5409   +/-   ##
=======================================
  Coverage   74.58%   74.58%           
=======================================
  Files         512      512           
  Lines       18666    18666           
  Branches     3659     3659           
=======================================
  Hits        13922    13922           
  Misses       3869     3869           
  Partials      875      875           

☔ 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.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 247a9f0. Configure here.}

[philprime]

LGTM from a code-level review perspective.

Regarding the duplicate SDKs:

The published SentryObjC target is designed as a full replacement for the Sentry target. Therefore, bundling both published frameworks would result in duplicate SDK framework slices. Given that the .NET SDK still depends on Sentry, building SentryObjC and SentryObjCCompat from source as thin frameworks seems like a reasonable interim solution for this pull request.

As a follow-up, I propose migrating the remaining bindings from Sentry to SentryObjC. Most types should have one-to-one replacements, and this would allow the SDK to ship only SentryObjC. We plan to remove Objective-C compatibility from the Sentry target in the next major release later this year, so completing that migration will be important.

[jamescrosswell]

As a follow-up, I propose migrating the remaining bindings from Sentry to SentryObjC. Most types should have one-to-one replacements, and this would allow the SDK to ship only SentryObjC. We plan to remove Objective-C compatibility from the Sentry target in the next major release later this year, so completing that migration will be important.

Ah, great - thanks @philprime !

[jpnurmi]

I couldn't find anything blocking either. Just a couple of nitpicks. 😅

[jpnurmi]

maybe worth something like Sentry(ObjC|ObjCCompat)?\.xcframework\\ios-arm64_x86_64-simulator pattern match?

[jpnurmi]

Side-note: arbitrary checkouts worked with a standalone clone, but I recall the automatic submodule update in before.Sentry.sln.targets fights back when trying to do this with submodules:

sentry-dotnet/before.Sentry.sln.targets

Lines 1 to 6 in 65c0c59

	<Project InitialTargets="RestoreSubmodule">
	<!-- Always restore, to apply changes when we change branches. If no changes happened, this is pretty quick so no need to optimize by adding a Condition -->
	<Target Name="RestoreSubmodule">
	<Exec Command="git submodule update --init --recursive" />
	</Target>
	</Project>