iOS: app crashes at launch (SIGSEGV in +[SentrySDKInternal startWithOptions:]) when the DSN is invalid — RNSentryStart starts the SDK with nil options #6822

Versions: @sentry/react-native 8.17.2, Sentry (Cocoa) 9.19.1, React Native 0.83.6 (New Architecture, prebuilt), Expo SDK 55, iOS 26.6.2 (device) and the iOS Simulator.

What happens

If Sentry.init({ dsn }) receives a string that the native SentryDsn parser rejects (in our case an unexpanded build variable, "$SOME_ENV_VAR"), the app crashes with EXC_BAD_ACCESS / KERN_INVALID_ADDRESS at 0x10 about 0.4 s after launch. The crash happens on the main thread, inside the initNativeSdk TurboModule call. Nothing reaches Sentry, because the crash happens while Sentry itself is starting.

Symbolicated stack (local Release build, lldb)

#0 +[SentrySDKInternal startWithOptions:]  options=0x0  SentrySDKInternal.m:246
       options.initialScope([[SentryScope alloc] initWithMaxBreadcrumbs:options.maxBreadcrumbs])
#1 SentrySDK.start(options: nil)                          SentrySDK.swift:121
#4 +[RNSentryStart startWithOptions:jsSdkVersion:]  options=0x0   RNSentryStart.m:44
#5 +[RNSentryStart startWithOptions:error:]                       RNSentryStart.m:24
#6 -[RNSentry initNativeSdk:resolve:rejecter:]                    RNSentry.mm:188

Cause

In RNSentryStart.m, +startWithOptions:error: calls createOptionsWithDictionary:error:. When PrivateSentrySDKOnly optionsWithDictionary:didFailWithError: fails (for example, on an invalid DSN), that returns nil and sets *errorPointer. +startWithOptions:error: doesn't check for this. It goes on to updateWithReactDefaults: and updateWithReactFinals: (both no-ops on nil), then calls [self startWithOptions:nil jsSdkVersion:…], which calls [SentrySDK startWithOptions:nil]. SentrySDKInternal then calls the nil options.initialScope block. initNativeSdk checks error only after this, and by then the app has already crashed.

Repro

1. In a Release iOS build, call Sentry.init({ dsn: "$NOT_A_DSN", enableNative: true }).
2. Launch the app. It crashes as shown above.
3. With a well-formed DSN, it launches normally.

Expected

RNSentryStart startWithOptions:error: should return early when createOptionsWithDictionary fails, so initNativeSdk rejects with the parse error (SentryReactNative) and the app keeps running without native Sentry. Separately, SentrySDKInternal startWithOptions: could guard against nil options, since its Objective-C signature doesn't prevent nil.

Workaround we shipped: validate the DSN shape in JS before Sentry.init, and fail our build when the configured DSN is invalid.