Changes for major version 9

[armcknight]

Let's discuss the breaking changes we'd like to see that are waiting on the next major version, à la #877 and #1094

Ideally we target September for release, to coincide with new versions of Xcode and Apple end-user device OSes.

[armcknight]

Integration installation. Per #2941, we dynamically construct integrations based on a list of strings representing their class names. This technically allows for customers to inject their own custom integration classes. It's not clear if this should be supported, how it would work, or what benefit customers can gain from doing so.

The dynamic strategy also discards type safety. We should not do so for the sake of our own convenience. We should figure out a way to do this with a simple API that doesn't rely on stringly typed logic. It should be enough for the boolean properties already present on SentryOptions to control which integrations are enabled or disabled. From there we can have a static code sector that sets things up. No need for looping through strings, using NSClassFromString etc. SentryOptions.integrations should no be a publicly exposed property at all.

[armcknight]

Rename SentryMechanismMeta to something else different than Meta. See #2888 for discussion.

[philipphofmann]

Tracked with #2888.

[armcknight]

Found a @todo headerdoc comment stating that SentryDebugImageProvider should be renamed to SentryDebugImage:

sentry-cocoa/Sources/Sentry/Public/SentryDebugImageProvider.h

Line 30 in 98713e6

* @todo This class should be renamed to @c SentryDebugImage in a future version.

[philipphofmann]

False alarm. I removed the comment with #6051.

[armcknight]

Remove obsoleted public methods in SentryDebugImageProvider deprecated in #3042.

[philipphofmann]

Tracked with #6052.

[armcknight]

Update IPHONEOS_DEPLOYMENT_TARGET from 11 to 13. A lot of tooling and dependencies seem to be on iOS 13 now. We only test as far back as 13.7 in CI:

sentry-cocoa/.github/workflows/test.yml

Line 92 in 3de9971

test-destination-os: "13.7"

as that's what's supported in GitHub actions: https://github.com/actions/runner-images/blob/91e422a825d3941ea357a13a91b13d4f4fdc326d/images/macos/macos-11-Readme.md?plain=1#L272

[armcknight]

Similar to macOS versions. IMO whenever we release a major version, it should only support the versions that can actually be tested on CI.

[armcknight]

Per

sentry-cocoa/develop-docs/DECISIONS.md

Lines 388 to 403 in 4ec088a

	## Platform version support
	Date: March 11, 2025
	Contributors: @armcknight, @philipphofmann, @kahest
	We will support versions of each platform going back 4 major versions, but we support no version which is not debuggable by the current Xcode required to submit apps to stores. There are 3 considerations:
	1. The distribution of events we receive from the various versions of iOS etc in the wild.
	1. Xcode support. As of the time of this writing, the oldest version of Xcode that can still submit apps to the app store is Xcode 15, which supports back to iOS 12, while the current is iOS 18.
	1. GitHub Actions support. This dictates which versions we can automatically test. Their oldest [macOS runner image](https://github.com/actions/runner-images/tree/main/images/macos) is `macos-13` with support going back to iOS 16.1
	Our major-4 standard would place us right in the middle of the earliest Xcode and GitHub Actions supported versions, which seems like a reasonable standard.
	Those versions that cannot be automatically tested with GitHub Actions shall be declared as "best effort" support.
	See previous discussion at https://github.com/getsentry/sentry-cocoa/issues/3846.

, when iOS 19 comes out, we should move minimal support to iOS 15, with a likewise movement for the other platforms.

[philipphofmann]

Tracked with #3846

[armcknight]

Make sampleRate / tracesSampleRate / profilesSampleRate / SentryTracesSamplerCallback nonnull: #3529 (comment)

[brustolin]

If we don't need nullability we should stop using NSNumber

[philipphofmann]

We can't make these nonnull, as these are nullable by design. When they are null it means that the feature is disabled. Setting it to 0.0 means the feature is enabled, but all data gets discarded.

See Java and also JavaScript

[armcknight]

Hiding in favor of #2946 (comment)

[armcknight]

Remove the deprecated SentryUser.segment (#4092)

[philipphofmann]

Tracked with #4093.

[armcknight]

Change SentrySDK.configureScope from being a block-based API to just returning a scope. Making it a block confers no benefit and makes callsites more complicated because even thought it's not asynchronous, the compiler still enforces capture semantics.

[armcknight]

See #2946 (comment) for why it is a block, but this API needs to be improved.

[philipphofmann]

I think we will tackle this when we convert the public APIs to Swift. I don't think it's worth the effort to improve this now. Do you agree @philprime and @itaybre?

[armcknight]

Remove the public access to SentryHub.scope. The scope should only be accessible by customers via configureScope and it should come with a warning not to retain the provided instance outside the block.

SentryHub.scope has a property getter override that contains a @synchronized critical sector. This detail is unnecessarily hidden from callsites that call e.g. SentrySDK.currentHub.scope. The property should either be called synchronizedScope or the critical sector should be placed inside a method with a similar name.

If it is imperative to protect the thread safety of the property, we should extract it into its own objc interface that keeps the instance private and only exposes a method to access it in a synchronized way.

This would make all callsites that use the scope that require waiting on a lock more obvious that that is what is happening.

[philipphofmann]

I'm unsure which problems we will solve with this approach. The configureScope also access the internal scope property with the lock. Furthermore, we plan on merging the scope and the hub with this still in progress RFC getsentry/rfcs#122. I would delay this because this task might become obsolete. @philprime or @itaybre do you have strong opinions here or can we skip this for now?

[armcknight]

Remove all profiling API deprecated by #4851

[philipphofmann]

Tracked with #6054.

[philipphofmann]

Make ANRV2 the default ANR detection algorithm.

[philipphofmann]

Tracked with #6055.

[philprime]

Remove initializers and unify default values for options. At this point we have too ways of configuration, which increases complexity of maintenance. See #5210

[philipphofmann]

@philprime we already merged #5210. Could you please create a GH issue with the remaining work and add it to this Linear project please https://linear.app/getsentry/project/cocoa-sdk-900-19a03b661aba/issues

[philprime]

Change enableFileManagerSwizzling to be enabled by default (see #4880)

[philipphofmann]

Tracked with #4880

[noahsmartin]

Change configuration to be a bit more consistent. For example session reply is a simple property options.sessionReplay.sessionSampleRate = 1.0 but profiling is for some reason a closure: options.configureProfiling = { probably everything should be properties.

Also I think we can do better with preventing invalid configurations. For example app hang tracker doesn't need to be two bools (because what happens when you set both to true?) Instead we can use an enum like disabled/v1/v2

[armcknight]

I think we should actually go the other way and use a closure for the replay stuff too. A couple things:

• there are some things that need to know whether profiling was configured at all, versus configured one way or another (although this might become simpler and not a requirement once the older versions of profiling are removed). At least the way the session replay options are currently done, there is always an instance of the options object, even if it's never configured.
• A closure also prevents even the illusion of being able to change a setting after the SDK is started.
• Finally, the SDK start itself is a closure, so it seems in line to continue with that pattern (user feedback config is also a closure).

I don't care too much one way or the other but just wanted to add more context.

[philprime]

Just to add my two cents without strongly disagreeing with any of the mentioned points:

• It might be helpful to separate using closures for dynamic calls where additional context must be provided on-demand, e.g. SentrySDK.start or beforeSend, compared to static values like sample rates that should not be changed during execution. To me a closures imply that this might be called multiple times instead of just once.
• Lazy initialization is definitely better in a closure, but therefore also a different case we probably don't even have in the SDK.
• Seeing options as a data structure with pure values, rather than something which is called/built dynamically might make it easier to build different configuration variants in tests (mostly relevant to use) and especially in logs when debugging the SDK. If a user has dynamic logic in closures, it might not be deterministic anymore.

I also don't have a strong opinion on either one, but we should align it with all available options, and also create a guide as a reference when new options are introduced.

[noahsmartin]

Re: A closure also prevents even the illusion of being able to change a setting after the SDK is started. I had the exact opposite thought, because a closure could be called multiple times so a user might imagine it will keep updating. But I think I see what you're saying, that if you had an options object the user might thing they could change the values of the options after passing it to the SDK start function.

I think we can solve that with a value type, like a Swift struct. We'd still need to provide an objc compatible API, but at least for Swift we can make it compile time clear that it's passed by value not reference, so you can't change it

[philipphofmann]

This looks like a bigger discussion. I think our whole API could be drastically improved especially for Swift. It's not really Swifty. I would delay this and not do this in v 9.0.0. I think we should tackle this once we convert more of our APIs or all our APIs to Swift.

[philprime]

Investigate if this issue needs to be done in major due to potential breaking changes:
#5252

[philipphofmann]

Tracked with #5252.

[philprime]

We should add a full uninstall mechanism so that when stopping the SDK everything is returned to a clean state incl. swizzling

[philipphofmann]

Why does this have to be in the next major? If we need this, we can also do it in a minor.

[philprime]

Because uninstalling also means unswizzling, which can have a drastic impact as you mentioned in this PR comment.

[philipphofmann]

OK thanks for the info.

[philipphofmann]

Tracked with #6056.

[philprime]

Remove custom names in Swift for Objective-C types, e.g. SentryOptions is Options in Swift.

[philipphofmann]

Tracked with #6057

[noahsmartin]

Remove +[SentryDsn getStoreEndpoint] which is unused

[philipphofmann]

@noahsmartin, I think we should already mark getStoreEndpoint as deprecated.

[philipphofmann]

Tracked with #6058

[noahsmartin]

We can move SentrySerializable to an internal type since the details of how we serialize data doesn't need to be public API. This will let us experiment with other protocols, like Encodable, without having to change the public API

[philipphofmann]

@noahsmartin I think you opened a few PRs for this topic already. Is this already done? If not, can you please open a GH issue(s) and assign it to this linear poject: https://linear.app/getsentry/project/cocoa-sdk-900-19a03b661aba/issues.

[noahsmartin]

Remove getHash from the public interface of SentryDsn

[philipphofmann]

I think we can consider making SentryDsn internal. I can't think of a good use case for why this should be public. You set the DSN via a string on the options. The SentryOptions.parsedDSN can be internal as well.

[philipphofmann]

Tracked with #6059

[philprime]

#5401 introduces new settings for screenshot masking which are almost identical to session replay settings.

Both should inherit the shared types from a common type, e.g. SentryPrivacyOptions. This is similar to how it's implemented in Sentry Flutter.

[philipphofmann]

Tracked with #6060

[philipphofmann]

We keep track of issues for 9.0.0 in Linear for now https://linear.app/getsentry/project/cocoa-sdk-900-19a03b661aba/issues. If you want to fix something in 9.0.0 please create a GH issue and assign it to the project. If you want an improvement for 10.0.0 please also create a GH issue and add the breaking change label to it.