Investigate missing symbols with internal swizzling API

[philprime]

Description

This issue required the switch back from SentrySDK.internal.swizzle.instanceMethod back to the SentrySwizzle.h because of absent symbols: getsentry/sentry-react-native#6468

This needs to be investigated to find the real culprit.

Furthermore the usage in RNSentryInternal.swift seems to be more complicated than it should be, requiring pointer casting and manual wrapping:

// `SentryInternalSwizzleApi` in sentry-cocoa has no platform gating.
// We enable the wrapper on every UIKit-capable platform (iOS/tvOS/visionOS
// — matching `SENTRY_UIKIT_AVAILABLE`, which is what `SENTRY_HAS_UIKIT`
// resolves to in the RNSentry.mm caller). `os(iOS)` in Swift already
// covers Mac Catalyst, so no separate `targetEnvironment(macCatalyst)` is
// needed.
#if os(iOS) || os(tvOS) || os(visionOS)
/// Stable identity for the `RNSScreen.viewDidAppear:` swizzle so the underlying
/// `oncePerClass` bookkeeping in sentry-cocoa can dedupe re-entries.
private static var rnsScreenViewDidAppearKey: UInt8 = 0

/// Swizzles `-[RNSScreen viewDidAppear:]`, invoking `hook` before the original
/// implementation on every call. No-op when RNSScreen is unavailable.
@_spi(Private) @objc public static func swizzleRNSScreenViewDidAppear(hook: @escaping () -> Void) {
    guard let cls = NSClassFromString("RNSScreen") else { return }
    let selector = NSSelectorFromString("viewDidAppear:")

    // `withUnsafePointer(to:)` scopes the pointer's validity to the closure
    // body. Perform the entire swizzle call inside so we never rely on the
    // pointer surviving beyond the closure. The backing storage is a
    // `static var`, so the address itself stays stable across calls —
    // sentry-cocoa's `oncePerClass` bookkeeping continues to dedupe.
    withUnsafePointer(to: &rnsScreenViewDidAppearKey) { keyPtr in
        _ = SentrySDK.internal.swizzle.instanceMethod(
            selector,
            in: cls,
            mode: .oncePerClass,
            key: UnsafeRawPointer(keyPtr),
            factory: { getOriginal in
                let block: @convention(block) (AnyObject, ObjCBool) -> Void = { receiver, animated in
                    hook()
                    typealias OriginalIMP = @convention(c) (AnyObject, Selector, ObjCBool) -> Void
                    let original = unsafeBitCast(getOriginal(), to: OriginalIMP.self)
                    original(receiver, selector, animated)
                }
                return block as AnyObject
            }
        )
    }
}
#else
@_spi(Private) @objc public static func swizzleRNSScreenViewDidAppear(hook: @escaping () -> Void) {}
#endif

[linear-code]

COCOA-1675

[sentry-pierre]

Two concrete leads that might save a round-trip through the repo:

• Symbol visibility: SentryInternalSwizzleApi.instanceMethod forwards to SentrySwizzleWrapperHelper.swizzleInstanceMethod, which lives in _SentryPrivate. Because SentryInternalSwizzleApi.swift imports _SentryPrivate with @_implementationOnly, the ObjC class symbol may not be exported to binary-framework consumers (e.g. CocoaPods xcframework users). That fits the missing-symbol linker errors you saw in React Native.
• Platform gating: SentryInternalApi wraps performance, screenshot, replay, etc. in #if (os(iOS) || os(tvOS) || os(visionOS)) && !SENTRY_NO_UI_FRAMEWORK, but swizzle is compiled unconditionally. If the underlying SentrySwizzleWrapperHelper is absent on some platforms, the unconditional exposure would compound the symbol problem.

On the ergonomics side, the factory: @escaping (@escaping () -> IMP) -> Any signature forces every caller to do the unsafeBitCast dance themselves, whereas SentrySwizzle.h hides that inside the macro.

[philprime]

Continued the investigation and reported my results here.

tl;dr: the symbols are in the xcframework binary and I requested a reproducer to validate the linking errors first.

[philprime]

The problem has been resolved:

Ahhh shoot. Sorry! It turns out an internal native dependency had s.dependency 'Sentry', '~> 9.0' in the podspec, so it looks like we were running into a two-Sentry-provider ABI mismatch. SENTRY_USE_XCFRAMEWORK=0 was letting us compile against the same source module and bypass the mismatch

Ref: getsentry/sentry-react-native#6465 (comment)