iOS - Pay - App crashes when paying a non existent user

[jponikarchuk]

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: v9.3.64-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/13176926/test-cases/41237617
Email or phone of affected tester (no customers): htad26+ewv@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: iOS 26.3/iPhone 13
App Component: Money Requests

Action Performed:

1. Launch the app
2. Sign in with any account
3. Tap on FAB button > Start chat > Enter the email which doesn't have an expensify account
4. Once redirected to the DM, tap on plus icon > Pay user > Enter amount > Mark as paid

Expected Result:

The user is able to pay the non existent user

Actual Result:

The app crashes

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

logs.txt

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @rlinoz (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #85234 - "Introduce a Bottom Tab Navigator for Top-Level Navigation" by @WojtekBoman (Medium confidence)
Secondary Candidate: #88517 - "[No QA] Fix standalone NewDot debug builds to use debug compilation flags" by @mateuuszzzzz (Medium confidence)
Related Issues: #89090 (iOS - App crashes when soft killing the app), #89069, #89052 — all iOS-only crashes in same staging version

Recommendation: NEEDS INVESTIGATION

Cannot confirm root cause without crash logs. Two strong candidate PRs have been identified — both are App PRs. The primary candidate (PR #85234) changed iOS navigation behavior significantly; the secondary candidate (PR #88517) changed hermes-engine compilation settings in staging builds. The existence of multiple other unrelated iOS crashes in the same staging version (89090, 89069, 89052) suggests a systemic iOS issue that may be caused by either or both of these PRs.

Assigned: @WojtekBoman (PR #85234 author), @mateuuszzzzz (PR #88517 author), @ZhenjaHorbach and @mountiny (PR #85234 approving reviewers) from highest-confidence causing PR
Labels: Keeping DeployBlockerCash — this is an iOS App crash with no production reproduction; both candidate PRs are in Expensify/App

Detailed Analysis

Evidence

Candidate 1: PR #85234 — Introduce a Bottom Tab Navigator for Top-Level Navigation

This PR introduces a TAB_NAVIGATOR wrapping the existing fullscreen navigators (REPORTS_SPLIT_NAVIGATOR, SEARCH_FULLSCREEN_NAVIGATOR, etc.) and modifies iOS-specific navigation state handling across 130+ files. Relevant changes that could cause the pay-crash on iOS:

1. dismissModalWithReport changed for narrow (iOS) layout: Previously, on narrow layout (iOS), after sending money the code did navigate(reportRoute, {forceReplace: true}) directly. After PR Introduce a Bottom Tab Navigator for Top-Level Navigation #85234, it instead calls dismissModal({ afterTransition: () => { navigate(reportRoute) } }). If navigate inside afterTransition throws or encounters an unexpected navigation state (e.g., TAB_NAVIGATOR not fully resolved for an optimistic report ID), it can cause a crash on iOS.

2. revealRouteBeforeDismissingModal removed narrow-layout guard: Previously, this function had if (getIsNarrowLayout()) { Log.warn; return; }. PR Introduce a Bottom Tab Navigator for Top-Level Navigation #85234 removed this guard, meaning the function now runs on iOS narrow layout too. This function dispatches REPLACE_FULLSCREEN_UNDER_RHP which manipulates the TAB_NAVIGATOR state — a new code path that was never exercised on iOS before.

3. New iOS-specific useCustomRootStackNavigatorState: Modified to use ensureTabNavigatorRoutes which keeps the last 2 TAB_NAVIGATOR instances rendered. The interaction between this and the pre-insert mechanism for the send-money (PAY type from FAB) flow is a new code path on iOS.

4. isReportTopmostSplitNavigator behavior changed: Now checks getActiveTabName() inside a TAB_NAVIGATOR. This affects the shouldPreInsertReport logic in IOURequestStepConfirmation, potentially triggering pre-insert for the send money flow from a DM.

Candidate 2: PR #88517 — Podfile hermes-engine and React-Core rebuild

This PR moved the project directive in the iOS Podfile from per-target to global scope. The intent was to fix build configurations for the NotificationServiceExtension target (which was incorrectly using release settings for debug builds). As a side effect, the hermes-engine and React-Core pod checksums changed, meaning these components were recompiled with different build settings (SWIFT_OPTIMIZATION_LEVEL = -Onone, DEBUG_INFORMATION_FORMAT = dwarf, ENABLE_HERMES_DEBUGGER potentially enabled). This is a weaker candidate for THIS specific functional crash but may explain the systemic iOS crashes (particularly the native soft-kill crash in #89090 which is unlikely to be caused by JS navigation changes).

Verification

• src/libs/Navigation/Navigation.ts — modified by PR Introduce a Bottom Tab Navigator for Top-Level Navigation #85234, specifically dismissModalWithReport and revealRouteBeforeDismissingModal
• src/libs/Navigation/AppNavigator/createRootStackNavigator/useCustomRootStackNavigatorState/index.ios.ts — modified by PR Introduce a Bottom Tab Navigator for Top-Level Navigation #85234
• src/libs/Navigation/AppNavigator/createRootStackNavigator/GetStateForActionHandlers.ts — modified by PR Introduce a Bottom Tab Navigator for Top-Level Navigation #85234, specifically handleReplaceFullscreenUnderRHP
• ios/Podfile and ios/Podfile.lock — modified by PR [No QA] Fix standalone NewDot debug builds to use debug compilation flags #88517 (hermes-engine, React-Core checksums changed)

Both PRs are confirmed in the staging deploy checklist for v9.3.64-0.

The affected flow (plus > Pay user > Mark as paid) uses sendMoneyElsewhere which calls dismissModalAndOpenReportInInboxTab which calls Navigation.dismissModalWithReport — the function changed by PR #85234.

Root Cause

For PR #85234 hypothesis: The pay flow on iOS narrow layout previously used navigate(reportRoute, {forceReplace: true}) as a single synchronous navigation. After PR #85234, it uses dismissModal({ afterTransition: () => navigate(reportRoute) }) — an asynchronous two-step navigation. In the new TAB_NAVIGATOR state structure on iOS, navigating inside the afterTransition callback to a report (especially a new optimistic chat with a non-existent user) may encounter a navigation state inconsistency, causing a crash.

For PR #88517 hypothesis: Changing the Podfile to use debug Hermes compilation settings for staging builds (DebugAdHoc) enables the Hermes debugger protocol and debug-only runtime assertions. These could cause crashes when certain native iOS operations are performed (soft kill, specific JS execution patterns).

To confirm: Check the crash stack trace in the logs.txt attached to the issue. If the stack trace is in JavaScript/React Navigation code → PR #85234. If it's in native Hermes/ObjC code → PR #88517.