[Due for payment 2026-08-08] iOS - App crashes upon launch

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.47-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: N/A
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Exploratory - Critical User Impact
Device used: iOS 26.5/iPhone 13
App Component: Other

Action Performed:

1. Install and launch the iOS app

Expected Result:

The app should load normally

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

Bug7222531_1785486360994.video_2026-07-31_11-25-45.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7222531

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/808fb4e2cdb60d2c398b3598fd935ba11cae68017e2c51f23017d9b16eda132f

[melvin-bot]

Triggered auto assignment to @JS00001 (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.

[MelvinBot]

🔍 Deploy Blocker Investigation — iOS launch crash (v9.4.47-0)

Staging-only + iOS-only + immediate cold-launch crash points at a native/build change in the 9.4.47 checklist (#97529). Two PRs touch launch-critical native surface; grab the crash stack first to pick between them, then revert.

Primary suspect — #97452 "[No QA] Update iOS build workflows to Xcode 26.6" by mountiny (medium confidence)
Bumps the iOS build toolchain Xcode 26.2 → 26.6 (a 4-release jump). Best fit for an iOS-only + staging-only crash: JS/native source matches production, but the staging .ipa is now built by a different toolchain than the working production build. Large Xcode jumps commonly cause launch-time native failures (dyld "Symbol not found" / "Library not loaded", Swift-runtime linking changes). The PR description itself notes the previous two Xcode bumps each broke the staging deploy. Revert is YAML-only and low risk.

Secondary suspect — #96638 "Fix markdown cursor restore crash on IOU description focus" by x-dev90 (medium confidence)
Only App PR bumping a native dependency: @expensify/react-native-live-markdown 0.1.333 → 0.1.334, which also changed the RNLiveMarkdown pod and the hermes-engine checksum in ios/Podfile.lock. RNLiveMarkdown is a Nitro native module registering HybridObjects at startup; an ABI/codegen mismatch (or the hermes checksum change) can crash immediately on launch.

Recommended action: REVERT (confirm with crash log)

Pull the stack trace from the Sentry 9.4.47-0 staging release or the Applause crash log:

• dyld / symbol / linker / Swift-runtime failure, no JS frames → revert [No QA] Update iOS build workflows to Xcode 26.6 #97452
• RNLiveMarkdown / Nitro / hermes frames → revert Fix markdown cursor restore crash on IOU description focus #96638

If no trace is available immediately, revert #97452 first (cleanest, lowest-risk, best fit), then #96638 if the crash persists.

Investigation details

• All 43 App PRs in the checklist were reviewed by file list. Only these two touch native-launch-critical surface — [No QA] Update iOS build workflows to Xcode 26.6 #97452 changes the iOS compile toolchain, Fix markdown cursor restore crash on IOU description focus #96638 is the only PR touching ios/ + package.json (a native pod bump).
• Other startup-adjacent PRs (Derive app skeletons from queued requests #97115 skeletons, Redirect the root path to Home instead of the Inbox #97446 root-path redirect, Advance lastUpdateID for WRITE requests only after the deferred flush applies #97098 Onyx flush, Add native support for HTML tables in responses #94926 native HTML-table renderers) are pure JS/TS — they wouldn't be iOS-only nor produce an immediate cold-launch native crash.
• Mobile-Expensify native submodule bumps also landed in this release and remain a possible non-App source; the two App PRs above are the strongest App-side causes.
• Code refs: buildIOS.yml:53 (DEVELOPER_DIR pin, [No QA] Update iOS build workflows to Xcode 26.6 #97452); ios/Podfile.lock (RNLiveMarkdown 0.1.333 → 0.1.334, hermes checksum, Fix markdown cursor restore crash on IOU description focus #96638).
• Suggested folks to loop in: [No QA] Update iOS build workflows to Xcode 26.6 #97452 — mountiny, lakchote, mjasikowski; Fix markdown cursor restore crash on IOU description focus #96638 — x-dev90, mountiny, suneox.

---

Next Steps: Reply with @MelvinBot implement this to open a revert PR for the confirmed suspect, or @MelvinBot <feedback> to refine.

[x-dev90]

@JS00001 I tested this locally on iOS and could not reproduce the launch crash. The app launched and remained usable.

I don’t think #96638 is the likely cause because it only bumps @expensify/react-native-live-markdown to 0.1.334 and changes IOU Description/Merchant cancel-focus behavior. The upstream 0.1.334 package diff is web cursor-utils only, with no native iOS source changes.

Could you please share the exact crash logs/stack trace so I can investigate further? Thanks