[Due for payment 2026-05-11] [Due for payment 2026-05-07] [$250] iOS - Unable to swipe back from workspace settings when opened from Home

[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.64-18
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #85234
Email or phone of affected tester (no customers): sdsodijnosdjoij@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: iPhone 15 Pro Max / iOS 26.3
App Component: Other

Action Performed:

1. Launch Expensify app.
2. Create a workspace if there’s no workspace.
3. Kill and relaunch app (if you have opened Workspaces tab)
4. Go to Home.
5. Tap Create a workspace in Getting started section.
6. Swipe back on workspace settings page.

Expected Result:

App will return to Home.

Actual Result:

User is unable to swipe back from workspace settings when opened from Home.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7141419_1777486493343.ScreenRecording_04-30-2026_02-11-29_1.1.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022049636974572613841
• Upwork Job ID: 2049636974572613841
• Last Price Increase: 2026-04-29

Issue Owner

Current Issue Owner: @ZhenjaHorbach

[melvin-bot]

@mountiny recently merged #85234, but they are OOO right now, so I'll auto-assign someone else.

[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.

[melvin-bot]

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

[melvin-bot]

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

[OSBotify]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #85234 - "Introduce a Bottom Tab Navigator for Top-Level Navigation" by @WojtekBoman (High confidence)
Related Issues: None

Recommendation: REVERT

This is a major navigation architecture refactor that introduced a regression in swipe-back gesture handling on iOS. The PR changed how full-screen navigators are structured (from individual root stack screens to tabs inside a createBottomTabNavigator), and the new gesture-enable/disable logic in TabNavigator.native.tsx does not correctly handle the case where a user navigates to workspace settings from the Home tab.

Assigned: @WojtekBoman (PR author), @ZhenjaHorbach @mountiny (approving reviewers) from highest-confidence causing PR only
Labels: DeployBlockerCash kept (frontend bug in App repo). No label changes made.

📋 Detailed Analysis

Evidence

• The melvin-bot comment on the issue explicitly identifies PR Introduce a Bottom Tab Navigator for Top-Level Navigation #85234 as the recently merged PR that matches the regression.
• The issue is reproducible on staging only (version 9.3.64-18), and PR Introduce a Bottom Tab Navigator for Top-Level Navigation #85234 is listed in the current StagingDeployCash checklist.
• The PR merged on 2026-04-24 and completely restructured the top-level navigation by replacing individual root-stack full-screen navigators (ReportsSplitNavigator, SearchFullscreenNavigator, SettingsSplitNavigator, WorkspaceNavigator) with a createBottomTabNavigator (TAB_NAVIGATOR).

Verification

Affected files:

• /src/libs/Navigation/AppNavigator/Navigators/TabNavigator.native.tsx — newly created file that controls gesture state for the parent (root stack) navigator via parentNavigation.setOptions({gestureEnabled: !isRootScreen}).
• /src/libs/Navigation/AppNavigator/createRootStackNavigator/useCustomRootStackNavigatorState/index.ios.ts — changed the getShouldHidePreloadedRoutes condition from checking WORKSPACE_SPLIT_NAVIGATOR to WORKSPACE_NAVIGATOR.

Both files are direct outputs of PR #85234, confirming it modifies the code path responsible for the bug.

Root Cause

The TabNavigator.native.tsx introduced a useEffect that dynamically sets gestureEnabled on the parent root-stack navigator based on the focused route name. A set called TAB_ROOT_SCREENS_WITHOUT_GESTURE disables gestures for SCREENS.HOME, SCREENS.INBOX, SCREENS.SEARCH.ROOT, and SCREENS.SETTINGS.ROOT.

The intended design is: when the user drills into WORKSPACE.INITIAL from the Home tab's "Getting Started" section, the focused route becomes Workspace_Initial (not in the disabled set), so gestureEnabled should become true. However, the bug reproduction requires killing and relaunching the app after having had the Workspaces tab open. After a kill/relaunch, the app restores navigation state. In this restored state, the parentNavigation.setOptions call is made during the initial render before the focusedRouteName state settles. Additionally, the iOS-specific getShouldHidePreloadedRoutes function was changed to treat the entire WORKSPACE_NAVIGATOR tab as a full-screen navigator that hides preloaded routes — this interacts with the gesture system in a way that can leave the swipe gesture disabled when transitioning from the Home tab into workspace settings pages.

The combination of: (1) gesture state being controlled dynamically via useEffect with a dependency on focusedRouteName, (2) the tab navigator's freezeOnBlur: true option potentially delaying state updates, and (3) the changed iOS preloaded-route hiding logic for WORKSPACE_NAVIGATOR, results in the swipe-back gesture remaining disabled when the user opens workspace settings from the Home tab's Getting Started section.