Conversation
Remove usage of the objectivesharpie Homebrew cask to avoid dependency on Rosetta. This homebrew version is an outdated x86_64 Mono application that needs Rosetta, and it only emits usable bindings alongside a separate Xamarin.iOS installation which also needs Rosetta. The dotnet tool runs natively on Apple silicon and carries its own .NET binding profile, so neither is required. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The newest version of Sharpie generates the ApiDefinition.cs file name as singular instead of plural. This commit changes our files to the new standard. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ric-oliv
requested review from
bruno-garcia and
jamescrosswell
and removed request for
jamescrosswell
September 16, 2026 13:07
There was a problem hiding this comment.
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.
Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 4b177b9. Configure here.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #5583 +/- ##
==========================================
- Coverage 74.76% 74.75% -0.01%
==========================================
Files 515 515
Lines 18963 18963
Branches 3694 3694
==========================================
- Hits 14177 14176 -1
- Misses 3908 3909 +1
Partials 878 878 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
ric-oliv
force-pushed
the
build/switch-obj-sharpie-version
branch
from
September 16, 2026 13:56
c0eaa0c to
4c872ca
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

Summary
Replace usage of the old objectivesharpie Homebrew cask with the currently maintained Sharpie.Bind.Tool.
Rationale
The homebrew version is an outdated x86_64 Mono application that needs Rosetta, and it only emits usable bindings alongside a separate Xamarin.iOS installation which also needs Rosetta.
The dotnet tool runs natively on Apple silicon and carries its own .NET binding profile, so neither is required.
Rosetta support will be dropped on macOS 28, so this change already addresses this future breakage.
Notes
Regenerating the bindings with the newer Sharpie, besides changing the
ApiDefinitions.csfile name (plural -> singular), changes the generated binding for theNSUrlSessionDelegate(generated asINSUrlSessionDelegateinstead).This is not a breaking change, as this is not part of our public API:
SentryObjCOptionsis marked [Internal] by patch-cocoa-bindings.cs, so it compiles to an internal type inSentry.Bindings.Cocoaand never appears in any public contract.SentryOptions.Native.UrlSessionDelegateis stillpublic NSUrlSessionDelegate?- that file isn't in this diff.public NSUrlSessionDelegate?into the binding'sINSUrlSessionDelegateproperty; that's an implicit reference conversion, since Foundation.NSUrlSessionDelegate implementsFoundation.INSUrlSessionDelegate.Verified with Microsoft.DotNet.ApiCompat.Tool by building Sentry.dll and Sentry.Bindings.Cocoa.dll before and after the change: no breaking changes on either assembly, including --strict-mode (which also flags additions). Reading the property straight out of both assemblies' metadata gives the identical public signature Sentry.SentryOptions+NativeOptions.UrlSessionDelegate : Foundation.NSUrlSessionDelegate.
Incidentally the interface is the more faithful mapping: the Cocoa header declares
@property (nonatomic, weak, nullable) id<NSURLSessionDelegate> urlSessionDelegate;, and an id conforming to a protocol maps to the I-prefixed interface rather than the concrete class.#skip-changelog