[Due for payment 2026-06-26] [$500] IOS - App crashes intermittently when switching to classic view

[lanitochka17]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.3.67-3
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/13176927/test-cases/41237621
Email or phone of affected tester (no customers): gatantm+6320@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: iOS 16.7
App Component: User Settings

Action Performed:

1. Launch new expensify and login in gatantm+6320@gmail.com
2. Tap on Account
3. Tap on Troubleshoot
4. Tap on Switch to Expensify Classic
5. Tap on Menu > Try New expensify and repeat steps 3-4 if needed

Expected Result:

The app switches to new or classic without any issues

Actual Result:

The app intermittently crashes when switching to classic expensify

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

Bug7145945_1778067844244!Expensify-2026-05-06-143600.ips.txt

Bug7145945_1778067844244.RPReplay_Final1778067364.mp4

Bug7145945_1778067844243!Expensify-2026-05-06-143526.ips.txt

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022053596630771437287
• Upwork Job ID: 2053596630771437287
• Last Price Increase: 2026-06-23

Issue Owner

Current Issue Owner: @mallenexpensify

Issue Owner

Current Issue Owner: @mallenexpensify

[MelvinBot]

Proposal

What is the root cause of that problem?

This is a HybridApp build (version 9.3.67-3, iOS). When the user taps "Switch to Expensify Classic" on the Troubleshoot page, closeReactNativeApp fires three operations in rapid succession with no synchronization:

1. Navigation.clearPreloadedRoutes() — calls navigationRef.reset(), which synchronously triggers a full navigation state replacement and re-renders
2. Onyx.merge(ONYXKEYS.HYBRID_APP, {closingReactNativeApp: true}) — async and not awaited, triggers re-renders in subscribers like CustomStatusBarAndBackground
3. HybridAppModule.closeReactNativeApp() — native TurboModule call that begins tearing down the React Native surface

The native teardown from step 3 can proceed while Onyx merge callbacks from step 2 are still dispatching React re-renders. On iOS 16.7, this race causes an access to deallocated memory (EXC_BAD_ACCESS) when React Native attempts to update UI (e.g., status bar style) after the native view hierarchy has already begun teardown. The intermittent nature matches a classic race condition — the crash only occurs when the Onyx-triggered re-render lands during the native teardown window.

Additionally, ScreenWrapper has a usePreventRemove hook that can also invoke closeReactNativeApp on back-navigation, creating a potential double-invocation scenario.

What changes do you think we should make in order to solve the problem?

Ensure the native closeReactNativeApp call does not execute while React re-renders are still in flight:

1. Await the Onyx merge before calling the native module — make closeReactNativeApp async and await Onyx.merge(...) before calling HybridAppModule.closeReactNativeApp(). This guarantees all Onyx-triggered re-renders complete before native teardown begins.

2. Add a guard against double invocation — add a module-level isClosing flag that is set to true at the start of closeReactNativeApp and prevents re-entry from the ScreenWrapper usePreventRemove hook or repeated taps.

What alternative solutions did you explore? (Optional)

• Wrapping the native call in requestAnimationFrame or InteractionManager.runAfterInteractions: This would defer the native call until after pending UI work, but is less deterministic than awaiting the Onyx merge directly — the timing depends on the React scheduler and could still race on slower devices.
• Moving clearPreloadedRoutes after the native call: This would eliminate the navigation reset re-render, but the Onyx merge re-render would still race with native teardown, so it doesn't fully solve the problem.

Investigation details

Entry point: TroubleshootPage.tsx:131-133 — for HybridApp builds, the menu item directly calls closeReactNativeApp({shouldSetNVP: true, isTrackingGPS}).

Race condition sequence:

1. clearPreloadedRoutes() resets navigation state → triggers synchronous re-renders
2. Onyx.merge() queues async state update → triggers re-renders in CustomStatusBarAndBackground and other HYBRID_APP Onyx subscribers
3. HybridAppModule.closeReactNativeApp() calls native TurboModule → begins tearing down RN surface
4. Onyx callback fires, React tries to update status bar on a deallocated native view → crash

Secondary invocation path: ScreenWrapper at index.tsx:182-192 uses usePreventRemove which can also trigger closeReactNativeApp, potentially double-invoking the flow.

Why iOS 16.7 specifically: iOS 16.x had known issues with UIKit view hierarchy mutations during transitions. The navigationRef.reset() combined with concurrent native teardown is more likely to hit these edge cases on older iOS versions.

Confidence: Medium — code analysis strongly supports the race condition hypothesis, but without access to the .ips crash stack trace or Sentry data, I cannot confirm the exact native frame where the crash occurs.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

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

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-10 22:46:11 UTC.

Replaces my earlier proposal. The prior body correctly identified the unawaited HybridApp closing flag, but it placed the fix after Navigation.clearPreloadedRoutes(). Verified flow shows the navigation reset itself runs before the guard is queued, so the guard must be applied and flushed before that reset; the iOS background-animation path was also overstated because background-only updates no-op on iOS.

Proposal

Please re-state the problem that we are trying to solve in this issue.

On iOS HybridApp, tapping Account > Troubleshoot > Switch to Expensify Classic can intermittently crash the app instead of cleanly switching from NewDot back to Expensify Classic.

What is the root cause of that problem?

The Troubleshoot menu item calls the shared HybridApp close action directly: TroubleshootPage.tsx#L131-L134.

Inside closeReactNativeApp(), the current order is wrong: it clears preloaded routes first, then queues HYBRID_APP.closingReactNativeApp = true, then immediately calls the native close bridge: HybridApp/index.ts#L112-L118. The route clearing calls navigationRef.reset(...): Navigation.ts#L928-L930.

That ordering defeats the existing guard. CustomStatusBarAndBackground disables itself when closingReactNativeApp is true: CustomStatusBarAndBackground/index.tsx#L27-L31. But because Navigation.clearPreloadedRoutes() runs before the Onyx write is even queued, the status-bar navigation listener is still active: CustomStatusBarAndBackground/index.tsx#L156-L170. That listener can still run updateStatusBarStyle(), which calls updateStatusBarAppearance({statusBarStyle}): CustomStatusBarAndBackground/index.tsx#L109-L111, updateStatusBarAppearance/index.ios.ts#L4-L8.

The attached crash logs are unsymbolicated, but they match this native teardown race shape: both are iOS 16.7 Expensify 9.3.67.4 EXC_BAD_ACCESS / SIGSEGV crashes at 0x0, faulting on thread 0 / com.apple.main-thread.

What changes do you think we should make in order to solve the problem?

Move the HybridApp closing guard before any navigation cleanup and wait for it to propagate before handing control to native.

In src/libs/actions/HybridApp/index.ts, keep the existing early returns for locked users, GPS handoff, and shouldBlockOldAppExit(). After those checks, when CONFIG.IS_HYBRID_APP is true, first merge ONYXKEYS.HYBRID_APP with {closingReactNativeApp: true}. After that promise resolves, defer the remaining UI teardown to the next frame, then call Navigation.clearPreloadedRoutes() and HybridAppModule.closeReactNativeApp({shouldSetNVP}). The next-frame defer matches the local timing guidance for UI updates that need to happen after a state flush: INTERACTION_MANAGER.md#L41-L45.

This mirrors the existing HybridApp pattern where setUseNewDotSignInPage(false) returns the Onyx merge promise and the caller chains the next close step after it resolves: HybridApp/index.ts#L132-L138, HybridApp.ts#L115-L118. The reopen path already resets closingReactNativeApp back to false: Session/index.ts#L750-L754.

Add/update unit coverage in tests/unit/HybridAppActionsTest.ts so the HybridApp close path asserts the ordering: no route clearing or native close before the closing-state write resolves, then both happen after the deferred flush.

Scope boundaries:

• Files touched: src/libs/actions/HybridApp/index.ts - closeReactNativeApp() around lines 98-118; tests/unit/HybridAppActionsTest.ts - close ordering coverage around the existing close tests.
• Platforms: iOS/Android HybridApp through the shared close action; reported crash is iOS-specific.
• Code paths / callers explicitly NOT touched: no direct changes to Troubleshoot UI, Account settings UI, GPS modal UI, 2FA/merge-account screens, OldDot native implementation, or CustomStatusBarAndBackground rendering logic.
• API contracts or backend behavior changes: no.

What alternative solutions did you explore? (Optional)

I considered only awaiting Onyx.merge() after Navigation.clearPreloadedRoutes(). That fixes the native bridge being called before the flag resolves, but it still lets the navigation reset run while closingReactNativeApp is false, so the status-bar listener remains active during the reset.

I also considered canceling statusBarAnimation in CustomStatusBarAndBackground. That is not the primary iOS path here: the Reanimated reaction schedules updateStatusBarAppearance with only backgroundColor, and the iOS implementation returns when statusBarStyle is missing: updateStatusBarAppearance/index.ios.ts#L4-L8. The verified direct iOS StatusBar.setBarStyle path is the navigation listener running before the closing guard is observed.

[melvin-bot]

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