App Gets Stuck on Splash Screen When Offline, More Frequent on Newer iOS Devices

[frederikchrlarsen]

OS:

• [ ] Windows
• [ ] MacOS
• [x] Linux

Platform:

• [x] iOS
• [ ] Android (not observed, but potentially)

SDK:

• [x] @sentry/react-native (>= 1.0.0)
• [ ] react-native-sentry (<= 0.43.2)

SDK version: Expo SDK 51 installs @sentry/react-native ~5.22.0

react-native version: 0.74.2

Are you using Expo?

• [x] Yes
• [ ] No

Are you using sentry.io or on-premise?

• [x] sentry.io (SaaS)
• [ ] on-premise

Configuration:

import * as Sentry from "@sentry/react-native";

import conf from "./src/configurations";
import App from "./src/index";

Sentry.init({ dsn: conf.sentryDSN, maxValueLength: 2000 });

export default Sentry.wrap(App);

What App is does not make any difference

---

I have the following issue:

Our React Native app occasionally gets stuck on the splash screen when starting without an internet connection (e.g., in flight mode or with network access removed via iOS settings). The issue is significantly more frequent on newer iOS devices:

• On an iPhone 13 running iOS 17.6.1, the app gets stuck around 8/10 times when starting offline.
• On an older iPad running iPadOS 17.6.1, the app gets stuck around 1/10 times when starting offline.

The issue does not occur when we remove or disable Sentry initialization (Sentry.init and Sentry.wrap):

import App from "./src/index";

export default App;

Findings: When offline, the app seems to be stuck while Sentry attempts to send network requests. Below are some relevant logs device logs:

standard 13:10:03.883208+0200 CommCenter NEPathEvent Cellular Blocked for com.xx by PID
standard 13:10:03.884133+0200 mDNSResponder [R239254] getaddrinfo stop -- hostname: <mask.hash: 'oDkK3tMcVHgN+9XXENO91Q=='>, client pid: 15949
standard 13:10:03.884161+0200 mDNSResponder [R239254] getaddrinfo stop -- hostname: <mask.hash: 'oDkK3tMcVHgN+9XXENO91Q=='>, client pid: 15949
standard 13:10:06.875499+0200 CommCenter NEPathEvent Cellular Blocked for com.xx by PID
standard 13:10:06.875521+0200 CommCenter NEPathEvent Cellular Blocked for com.xx by PID
standard 13:10:06.877036+0200  -[NWConcrete_nw_resolver initWithEndpoint:parameters:path:log_str:] [R21] created for Hostname#62a4ff05:0 using: generic, attribution: developer
standard 13:10:06.877293+0200  nw_resolver_set_update_handler_block_invoke [R21] started
standard 13:10:06.877057+0200  -[NWConcrete_nw_resolver initWithEndpoint:parameters:path:log_str:] [R21] created for Hostname#62a4ff05:0 using: generic, attribution: developer
standard 13:10:06.877315+0200  nw_resolver_set_update_handler_block_invoke [R21] started
standard 13:10:06.878015+0200 CommCenter NEPathEvent Cellular Blocked for com.xx by PID
standard 13:10:06.877993+0200 CommCenter NEPathEvent Cellular Blocked for com.xx by PID

Steps to reproduce:

• Run the app on a newer iOS device (e.g., iPhone 13).
• Disable internet access (e.g., enable flight mode or remove network access via settings).
• Launch the app multiple times and observe if it gets stuck on the splash screen.

Actual result:

The app some times get stuck on the splash screen when started in offline mode.

Expected result: The app should not get stuck on the splash screen when there is no internet connection. The Sentry SDK should handle offline scenarios gracefully.

Hypothesis: We suspect the issue is related to how the Sentry SDK handles offline scenarios:

• Faster Processing on Newer Devices: The issue is more frequent on newer devices, which suggests it could be a race condition or timing-related problem.
• Lack of Proper Offline Handling: It seems that the SDK is trying to send events or perform network operations even when the device is offline, without appropriate checks or fallbacks.

[kahest]

@frederikchrlarsen thank you for the report - this seems related/identical to https://github.com/getsentry/sentry-react-native/issues/3820 - can you verify if the issue persists with 5.22.3 or newer?

[frederikchrlarsen]

@kahest Thank you for the quick response! I can confirm that it is fixed on version 5.22.3. Sorry for bringing up an old and solved issue.

[kahest]

@frederikchrlarsen thanks for confirming! 🙏