[$250] [Sentry: APP-7FJ] HybridApp iOS Fatal App Hang at main

[mountiny]

Sentry

https://expensify.sentry.io/issues/APP-7FJ

Impact (snapshot at filing)

• Users (last 14d): ~21
• Platform: iOS, hybrid_app (HybridApp)
• Mechanism: AppHang, fatal — watchdog termination after 2000ms main-thread block

Stack trace

Sentry's only first-party-resolvable frame is main — the body of the hang is below symbolication. We need a re-symbolicated event before we can point at a code site.

First investigation step

Re-symbolicate a recent event in Sentry against the matching dSYM (the dSYM for the corresponding release should already be uploaded). Once frames resolve, group by the deepest first-party frame and re-triage.

Why this is filed separately from APP-7CX

APP-7CX has a clear culprit (+[YAPLJS callFunction:args:] re-entrancy) and is already tracked in App#91229. APP-7FJ's only resolvable frame is main, so it could be any of:

• A different JS path that also blocks the main thread for 2000ms+
• A native UIKit / dispatch deadlock unrelated to JS
• A separate library re-entrancy issue

Keeping it as its own issue until we can see the deeper stack.

Reproduction

Unknown.

Related

• Sibling Sentry IDs (if any): none confirmed; potentially overlaps with APP-7CX (App#91229) once frames resolve.
• Prior GH issues: none.

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022057427688022436891
• Upwork Job ID: 2057427688022436891
• Last Price Increase: 2026-05-21

[MelvinBot]

Issue Analysis

⚠️ Preliminary analysis (medium confidence) — the root cause cannot be confirmed until Sentry events are re-symbolicated with the correct dSYM.

Root Cause: Unknown — the Sentry stack trace only resolves to main, so the specific code path causing the 2000ms+ main-thread block is not yet identifiable. However, a codebase audit reveals several candidate main-thread blocking patterns in the HybridApp iOS build that could individually or cumulatively exceed the 2000ms watchdog threshold.

Recommended Next Step: Re-symbolicate a recent APP-7FJ event against the matching dSYM. Once frames resolve, match the deepest first-party frame against the candidates below to confirm the culprit.

Candidate main-thread blocking sites (ranked by risk)

1. RCTBootSplash.constantsToExport — synchronous main-queue dispatch during module init

RCTBootSplash.mm:143 calls RCTUnsafeExecuteOnMainQueueSync() to read dark-mode state. If constantsToExport is called from the JS thread during module initialization while the main thread is already busy (e.g., during didFinishLaunchingWithOptions), this creates a deadlock-prone synchronous cross-thread dispatch. Combined with Fabric/TurboModule initialization, this is the highest-risk candidate for a 2000ms+ hang.

Additionally, the BootSplash module explicitly routes all its methods to the main queue (line 20-22).

2. AppDelegate.didFinishLaunchingWithOptions — synchronous startup chain

AppDelegate.swift:23-73 runs several heavy operations synchronously on the main thread:

• React Native startup (factory.startReactNative()) — line 34
• Firebase init (FirebaseApp.configure()) — line 40
• Storyboard instantiation (RCTBootSplash.initWithStoryboard) — line 49
• Airship LiveActivity setup — lines 64-70
• Multiple UserDefaults reads/writes — lines 25, 56-58

On older devices, these operations cumulatively could approach or exceed 2000ms.

3. Distinction from APP-7CX (#91229)

APP-7CX has a clear +[YAPLJS callFunction:args:] re-entrancy culprit. APP-7FJ's main-only trace suggests a different hang mechanism — likely startup-phase blocking rather than mid-session JS callback re-entrancy. The two issues should remain separate until symbolication proves otherwise.

Possibly related issues

• Expensify/App#91292 — APP-7B2: HybridApp iOS fatal hang in Fabric ComponentDescriptorRegistry (same platform, different mechanism)
• Expensify/App#91229 — APP-7CX: HybridApp iOS fatal hang in YAPLJS callFunction (sibling issue, already noted in this issue)

Actionable next steps

1. Re-symbolicate a recent APP-7FJ event in Sentry against the matching dSYM — this is the blocker
2. Once frames resolve, check if the deepest frame matches any of the candidates above
3. If the hang is in constantsToExport / RCTUnsafeExecuteOnMainQueueSync, the fix is to make RCTBootSplash return constants lazily or move dark-mode detection off the synchronous path
4. If the hang is in didFinishLaunchingWithOptions, consider deferring Firebase and Airship setup to a background queue or post-launch callback

---

Next Steps: Reply with @MelvinBot <your feedback> to refine this analysis.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @Krishna2323 (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022057427688022436891