The #if os(iOS) || os(tvOS) guard in RNSentryInternal.swift makes setCurrentScreen an empty stub on visionOS, but RNSentry.mm calls [RNSentryInternal setCurrentScreen:screen] under #if SENTRY_HAS_UIKIT — which also resolves true on visionOS. As a result, breadcrumb current-screen enrichment is silently dropped on visionOS with no caller-visible indication, whereas the previous PrivateSentrySDKOnly.setCurrentScreen worked under SENTRY_UIKIT_AVAILABLE (including visionOS). The code comment explicitly acknowledges this as an accepted tradeoff aligned with sentry-cocoa's new hybrid API, so this is a documented, intentional regression worth confirming rather than a defect.

Have you considered adding smoke tests for the three new profiling bridge methods in RNSentryInternalTests.swift? The swizzle bridge has testSwizzleRNSScreenViewDidAppearNoOpWhenClassMissing, but the profiling path — which is called from production code in RNSentry.mm — has no corresponding coverage.

Also found at:

• packages/core/ios/RNSentryInternal.swift:131-133

In SentryScreenFramesWrapper.m, totalFrames/frozenFrames/slowFrames each call canTrackFrames (which reads RNSentryInternal.currentScreenFrames) and then read currentScreenFrames a second time. If the frames tracker stops between these two accesses, the nil ObjC property read returns 0, so the caller in RNSentry.mm resolves with @{"totalFrames": @0, ...} instead of nil, reporting incorrect zeroed frame data to JavaScript.

In RNSentryInternal.swift, swizzleRNSScreenViewDidAppear obtains keyPtr via withUnsafePointer(to: &rnsScreenViewDidAppearKey) and passes UnsafeRawPointer(keyPtr) as the key: argument to SentrySDK.internal.swizzle.instanceMethod(_:in:mode:key:factory:). For .oncePerClass deduplication, sentry-cocoa retains that key pointer beyond the closure. Swift's withUnsafePointer(to:) only guarantees the pointer is valid within the closure body, so retaining it afterward is formally undefined behavior. In practice rnsScreenViewDidAppearKey is a static var with stable global storage, so no crash occurs today and the dedup key remains stable across calls; this is a low-severity correctness/idiom concern rather than an exploitable bug.