[$250] Update required screen shown on latest iOS staging build after stale NewDot bundle sends outdated appversion

[mountiny]

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.4.25-1 (native shell) / stale NewDot bundle 9.3.91-0
Reproducible in staging?: Needs Reproduction (Unable to reproduce — single isolated server-side event)
Reproducible in production?: Needs Reproduction
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers): cole@expensify.com
Logs: VictoriaLogs investigation — request_id a143bbd4a9ef3335-SJC on 2026-07-01T07:35:23Z
Expensify/Expensify Issue URL:
Issue reported by: @vit (internal investigation)
Slack conversation: #Expensify Bugs — cole reported 2026-07-02 ~4:39 PM

Action Performed:

1. Open the iOS native app on the latest TestFlight staging build
2. Use the app normally (background/resume)
3. Observe the full-screen Update required blocker

Expected Result:

Users on the latest staging build should never see the forced-update screen.

Actual Result:

cole@expensify.com saw the Update required / Please update to the latest version of New Expensify screen on iOS native TestFlight while already on the latest staging build. Hard-quitting the app cleared the screen and the app worked normally afterward.

Workaround:

Force-quit and reopen the app.

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Issue observed in the following devices

• iOS (TestFlight staging)
• Native shell: Expensify/9.4.25.1 CFNetwork/3860.600.12 Darwin/25.5.0
• Screenshot attached in Slack thread (IMG_3948.PNG)

Screenshots/Videos

See Slack thread screenshot — full-screen Update Required blocker with green Update button.

---

Investigation summary (for implementers)

What triggered the screen

The forced-update UI is shown when any authenticated API returns jsonCode: 426:

1. Backend (Web-Expensify/lib/Request.php) compares appversion param against MINIMUM_APP_VERSION (9.4.9 at time of incident)
2. Frontend (App/src/libs/HttpUtils.ts) calls alertUser() → sets ONYXKEYS.RAM_ONLY_UPDATE_REQUIRED
3. App/src/Expensify.tsx throws CONST.ERROR.UPDATE_REQUIRED → error boundary renders App/src/pages/ErrorPage/UpdateRequiredView.tsx

The flag is RAM-only (App/src/setup/index.ts ramOnlyKeys) and is never cleared in-session — only a process restart resets it. That explains the self-recovery after hard-quit.

Server logs for cole@expensify.com (2026-07-01)

Exactly one request triggered the 426 across the entire Jun 15 – Jul 3 window:

Field	Value
Timestamp	2026-07-01T07:35:23Z
request_id	a143bbd4a9ef3335-SJC
command	ReconnectApp
platform	ios
referer	ecash
appversion in request body	9.3.91-0
nginx User-Agent (native shell)	Expensify/9.4.25.1
minimum at time	9.4.9
needsUpgrade	true
jsonCode	426

Log sequence:

[ForceAppUpgrade] Comparing app version to minimum ~~ appVersion: '9.3.91-0' minimum: '9.4.9' needsUpgrade: '1'
Deprecated app version detected - forcing the user to upgrade
API threw ExpError ... exceptionJsonCode: '426'

All other cole requests that day used current versions (ecash9.4.24-0, ecash9.4.25-1, iphone9.4.25-1). The stale ecash9.3.91-0 source appeared once total.

Root cause hypothesis

The iOS HybridApp ran a stale NewDot JS bundle (9.3.91-0) inside a current native shell (9.4.25.1). The appversion sent on API calls comes from bundled package.json (App/src/libs/Network/enhanceParameters.ts → appversion: pkg.version), so it reflected the old JS bundle, not the native binary version.

On app resume, ReconnectApp fired with the stale version → backend correctly returned 426 → client stuck on Update Required until restart loaded a fresh bundle.

Open question for implementer: How did HybridApp retain/serve bundle 9.3.91-0 after a TestFlight update to 9.4.25? Investigate bundle loading, OTA update, and cache invalidation in Mobile-Expensify / @expensify/react-native-hybrid-app.

What this is NOT

• Not a backend false positive — version_compare('9.3.91-0', '9.4.9', '<') is correct
• Not cole running an actually outdated build — native User-Agent confirms 9.4.25.1
• Not related to the recent minimum-version bump logic being wrong — the stale bundle predates the bump

Proposed fix direction

1. Investigate HybridApp bundle lifecycle — ensure NewDot JS bundle version always matches or is invalidated when native app updates (TestFlight/OTA)
2. Add defensive logging — when native shell version ≠ bundled pkg.version, log/Sentry so future occurrences are diagnosable
3. (Optional follow-up, separate issue) — auto-recover from transient 426 if subsequent requests succeed with current version

Key files

• App/src/libs/Network/enhanceParameters.ts — sends appversion
• App/src/libs/HttpUtils.ts — detects 426
• App/src/libs/actions/UpdateRequired.ts — sets RAM-only flag
• App/src/pages/ErrorPage/UpdateRequiredView.tsx — UI
• Mobile-Expensify / HybridApp bundle loading (primary investigation target)

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022072936567612010703
• Upwork Job ID: 2072936567612010703
• Last Price Increase: 2026-07-03

Issue Owner

Current Issue Owner: @mkhutornyi

[melvin-bot]

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

[melvin-bot]

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

[kitvasyl]

Proposal

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

A current iOS TestFlight build can incorrectly show the blocking Update Required screen when a stale NewDot JavaScript bundle sends its bundled version to the API.

What is the root cause of that problem?

src/libs/Network/enhanceParameters.ts always sets appversion from package.json. In HybridApp, that value describes the loaded JavaScript bundle rather than the installed native shell. Therefore, a stale bundle can send an outdated version, receive a 426 response, and trigger alertUser() in src/libs/HttpUtils.ts even though the native app is current.

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

Add a platform-specific app-version helper and use it in enhanceParameters(). Its native implementation should return DeviceInfo.getVersion() from react-native-device-info, while the web implementation should continue returning package.json's version. This ensures native requests report the installed binary version used to determine whether an App Store/TestFlight update is required, regardless of which embedded JS bundle is currently loaded.

Add focused tests confirming that enhanceParameters() uses the native shell version on native platforms and retains the package version on web.

What alternative solutions did you explore? (Optional)

Clearing or ignoring the update-required flag after a 426 would hide this incident, but it would also allow genuinely unsupported native versions to bypass the required-update screen. Correcting the version sent by native requests addresses the false 426 without weakening that protection.

[shivang-goliyan]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-03 07:00:53 UTC.

Proposal

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

A user on the latest iOS staging build got stuck on the full-screen "Update required" blocker even though they were already on the newest binary. Force-quitting and reopening cleared it. So the app is telling people to update when they don't need to, and once it happens they can't get out of it without killing the process.

What is the root cause of that problem?

There are two separate things going on here, and it helps to split them.

First, why the 426 fired at all. Every API request tags on appversion: pkg.version in getBaseRequestParameters at src/libs/Network/enhanceParameters.ts:72, where pkg is the bundled package.json (line 10). That is the JS bundle's version, not the native binary version. In this incident the native shell was current (User-Agent Expensify/9.4.25.1) but the running NewDot JS bundle was stale (9.3.91-0), so ReconnectApp advertised the old version and the backend correctly returned 426. The backend was right. The request just carried a version that didn't match the shell it was running in. Why a stale bundle survived the TestFlight update is a HybridApp bundle-lifecycle question (OTA / cache invalidation) that lives in Mobile-Expensify and @expensify/react-native-hybrid-app, not in this repo.

Second, and this is the part the App repo owns: once that 426 lands, the session can never recover on its own. HttpUtils.ts:197 calls alertUser() on JSON_CODE.UPDATE_REQUIRED, which does a single Onyx.set(RAM_ONLY_UPDATE_REQUIRED, true) in src/libs/actions/UpdateRequired.ts:6. Expensify.tsx:65 reads that flag and throws CONST.ERROR.UPDATE_REQUIRED, and the error boundary renders UpdateRequiredView. I grepped every reference to RAM_ONLY_UPDATE_REQUIRED and nothing anywhere sets it back to false. It's a RAM-only key (src/setup/index.ts:70), so the only thing that clears it is a process restart. That's exactly the "hard-quit fixes it" behavior in the report. A single stale/transient 426 permanently bricks the session until the app is killed, even after later requests go out with a perfectly current version.

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

The bundle-serving cause is native and should be tracked in Mobile-Expensify. What we can fix on the App side is the stuck-forever behavior and the blind spot that made this hard to diagnose.

Clear RAM_ONLY_UPDATE_REQUIRED when a later authenticated request comes back healthy with a current version. Add a small clearAlert() in UpdateRequired.ts that sets the flag back to false, and call it from the HttpUtils.ts response handler on the non-426 success path so a good response undoes a stale one. That turns a permanent block into a self-healing one without weakening the real forced-upgrade case, since a genuinely outdated client keeps getting 426 and the flag stays set.

Alongside that, add defensive logging in enhanceParameters (or right before alertUser()): compare the native binary version from react-native-device-info DeviceInfo.getVersion() against bundled pkg.version, and log/Sentry when they diverge on HybridApp. We already use react-native-device-info elsewhere, so this is a small addition that would have named this exact mismatch immediately. Neither area has a test asserting 426 recovery today, so I'd add one covering set-then-clear on a subsequent successful request.

What alternative solutions did you explore? (Optional)

Fix it purely in Mobile-Expensify by never serving a stale bundle after a native update. That addresses the trigger but leaves the App session with no way to recover if any transient 426 ever slips through, so it's worth doing but not sufficient on its own. I also considered logging-only (the version-mismatch signal) with no recovery change, but that just makes the next occurrence diagnosable while still forcing every affected user to force-quit.

[lorretheboy]

Proposal

What is the root cause of that problem?

This is not an App code defect — the App behaved as designed, but two designed behaviors combined to lock the user out:

1. On HybridApp iOS, the native shell had updated to 9.4.25, but the NewDot JS bundle that actually ran after the update was a stale 9.3.91 copy. The bundle loading/caching in Mobile-Expensify / @expensify/react-native-hybrid-app is not keyed to (or invalidated by) the native binary version, so a TestFlight update can leave an old extracted bundle in place until the process restarts. This is the true root cause and it lives in the Mobile-Expensify side, not in this repo.

2. appversion is the package.json version baked into the JS bundle at build time, so the stale bundle reported 9.3.91-0 even though the binary was 9.4.25:

App/src/libs/Network/enhanceParameters.ts

Line 72 in 3ad48ca

appversion: pkg.version,

3. ReconnectApp fired on resume with that stale version, the server correctly returned 426, and the client set the update-required flag:

App/src/libs/HttpUtils.ts

Lines 195 to 198 in 3ad48ca

	if (response.jsonCode === CONST.JSON_CODE.UPDATE_REQUIRED) {
	// Trigger a modal and disable the app as the user needs to upgrade to the latest minimum version to continue
	alertUser();
	}

4. That flag is RAM-only and nothing ever clears it in-session, so the error boundary blocker stays up until a process restart (which also loads the fresh bundle — that's why force-quit "fixed" it):

App/src/setup/index.ts

Line 70 in 3ad48ca

ONYXKEYS.RAM_ONLY_UPDATE_REQUIRED,

App/src/Expensify.tsx

Lines 281 to 283 in 3ad48ca

	if (updateRequired) {
	throw new Error(CONST.ERROR.UPDATE_REQUIRED);
	}

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

Two parts, matching the fix direction in the issue:

1. Mobile-Expensify / hybrid-app module (primary fix): key the loaded/extracted NewDot bundle to the native binary version (or a build hash) and discard it on mismatch, so an updated shell can never execute a previous bundle. This change belongs in the Mobile-Expensify repo/submodule.

2. This repo (defensive detection): add a one-time startup check on native builds that compares the native binary version (DeviceInfo.getVersion() from react-native-device-info, already a dependency) against the bundled pkg.version, and sends a Log.alert with both values when they disagree. Roughly:

const nativeVersion = DeviceInfo.getVersion();
if (CONFIG.IS_HYBRID_APP && !pkg.version.startsWith(nativeVersion)) {
    Log.alert('JS bundle version does not match native binary version', {jsVersion: pkg.version, nativeVersion});
}

Today the only evidence of this state is a body-vs-User-Agent mismatch buried in nginx logs; this makes any recurrence immediately visible server-side. We should not change what appversion sends — the JS bundle version is the correct value to gate API compatibility, and the 426 was correct given the bundle that ran.

What alternative solutions did you explore? (Optional)

Auto-recovering from the blocker by clearing RAM_ONLY_UPDATE_REQUIRED when a later request succeeds with a current version — rejected here because the flag deliberately halts an outdated client, and the issue scopes that as an optional follow-up. Also considered sending the native version as an extra request parameter so the server can distinguish "stale bundle" from "genuinely old app" in its own logs; that pairs well with the startup log but requires a Web-Expensify change.

[nabi-ebrahimi]

Proposal

What is the root cause of that problem?

The API appversion parameter is using the loaded NewDot JS bundle version instead of the installed native shell version. getBaseRequestParameters() always sends pkg.version for appversion, so a stale HybridApp bundle can report an old version even when the TestFlight binary is current ([source](https://github.com/Expensify/App/blob/main/src/libs/Network/enhanceParameters.ts#L60-L73)). Queued requests also seed request.data.appversion from the same JS package version ([source](https://github.com/Expensify/App/blob/main/src/libs/Network/index.ts#L49-L54)). When that stale value is below the backend minimum, the API returns jsonCode: 426; the client treats any 426 as update-required ([source](https://github.com/Expensify/App/blob/main/src/libs/HttpUtils.ts#L195-L198)), then Expensify reads RAM_ONLY_UPDATE_REQUIRED and throws the blocking update error ([source](https://github.com/Expensify/App/blob/main/src/Expensify.tsx#L65-L65), [source](https://github.com/Expensify/App/blob/main/src/Expensify.tsx#L281-L283)). That makes a current native app look outdated until the process restarts and the RAM-only flag is reset.

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

Add a small platform-specific app-version helper and use it everywhere we populate the API appversion field. The default/web implementation should keep returning pkg.version. The native implementation should return the installed native app version, not the JS bundle version.

For Android, the native version source can use DeviceInfo.getVersion() because Android’s versionName already matches the API/package format like 9.4.26-6 ([source](https://github.com/Expensify/App/blob/main/android/app/build.gradle#L114-L115)). For iOS, use the native bundle version and normalize it to the JS/API format by replacing the last dot with a hyphen, matching the existing native Sentry release formatting logic ([source](https://github.com/Expensify/App/blob/main/ios/SentryNativeSDKManager.m#L49-L54)); the iOS bundle currently stores CFBundleVersion as 9.4.26.6 while the API/package format is 9.4.26-6 ([source](https://github.com/Expensify/App/blob/main/ios/NewExpensify/Info.plist#L25-L47)).

Then update getBaseRequestParameters() to set appversion from this helper instead of pkg.version, so every request enhanced through the normal network path reports the installed app version on native ([source](https://github.com/Expensify/App/blob/main/src/libs/Network/enhanceParameters.ts#L60-L80)). Also update the queued-request seed in Network.post() to use the same helper instead of pkg.version, so persisted/queued request data is consistent with the enhanced request metadata ([source](https://github.com/Expensify/App/blob/main/src/libs/Network/index.ts#L49-L54)). Finally, update the existing enhanceParameters unit coverage to mock the helper and assert that appversion comes from the helper rather than directly from package.json.

What alternative solutions did you explore? (Optional)

I considered clearing or ignoring RAM_ONLY_UPDATE_REQUIRED after a restart/resume, but that would weaken the valid forced-update flow for genuinely unsupported native builds. I also considered fixing only the HybridApp stale-bundle cache, but the App API layer would still trust the wrong source of truth whenever a stale bundle is loaded.

[samranahm]

Proposal

What is the root cause of that problem?

On native HybridApp the version reported to the API describes the loaded JS bundle, not the installed native shell. In Network/index.ts every request hardcodes appversion: pkg.version:

App/src/libs/Network/index.ts

Lines 51 to 56 in 3ad48ca

	shouldRetry: data?.shouldRetry ?? true,
	canCancel: data?.canCancel ?? true,
	appversion: pkg.version,
	};
	// Add promise handlers to any request that we are not persisting

pkg.version comes from the bundled package.json. When a stale NewDot bundle (9.3.91-0) runs inside a current shell (9.4.25.1), the reconnect request carries 9.3.91-0. The backend correctly compares that against MINIMUM_APP_VERSION and returns 426, so the client is punished for a version the user is not actually running.

HttpUtils.ts then reacts to any 426 by unconditionally calling alertUser():

App/src/libs/HttpUtils.ts

Lines 195 to 199 in 3ad48ca

	if (response.jsonCode === CONST.JSON_CODE.UPDATE_REQUIRED) {
	// Trigger a modal and disable the app as the user needs to upgrade to the latest minimum version to continue
	alertUser();
	}
	return response;

alertUser() sets RAM_ONLY_UPDATE_REQUIRED:

App/src/libs/actions/UpdateRequired.ts

Line 5 in 3ad48ca

function alertUser() {

That key is RAM-only (setup/index.ts ramOnlyKeys), so it is never persisted and, more importantly, never cleared mid-session:

App/src/setup/index.ts

Lines 67 to 73 in 3ad48ca

	ONYXKEYS.DERIVED.RAM_ONLY_SORTED_REPORT_ACTIONS,
	ONYXKEYS.RAM_ONLY_IS_CHECKING_PUBLIC_ROOM,
	ONYXKEYS.RAM_ONLY_UPDATE_AVAILABLE,
	ONYXKEYS.RAM_ONLY_UPDATE_REQUIRED,
	ONYXKEYS.RAM_ONLY_IS_SEARCHING_FOR_REPORTS,
	ONYXKEYS.RAM_ONLY_IS_AUTHENTICATING_WITH_SHORT_LIVED_TOKEN,
	ONYXKEYS.RAM_ONLY_WALLET_ONFIDO,

Expensify.tsx reads the flag and keeps rendering the blocker until a process restart loads a fresh bundle, which is why hard-quit self-recovers:

App/src/Expensify.tsx

Lines 62 to 67 in 3ad48ca

	const {preferredLocale} = useLocalize();
	const [lastRoute] = useOnyx(ONYXKEYS.LAST_ROUTE);
	const [isCheckingPublicRoom = true] = useOnyx(ONYXKEYS.RAM_ONLY_IS_CHECKING_PUBLIC_ROOM);
	const [updateRequired] = useOnyx(ONYXKEYS.RAM_ONLY_UPDATE_REQUIRED);
	const [lastVisitedPath] = useOnyx(ONYXKEYS.LAST_VISITED_PATH);
	useDebugShortcut();

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

1. Fix the version at its source in Network/index.ts so native requests report the installed shell version, not the bundle. The native device version is already collected by the platform-specific device info module (getDeviceInfo, BaseInfo):

App/src/libs/actions/Device/getDeviceInfo/types.ts

Line 3 in 3ad48ca

type BaseInfo = {

Add a small platform-specific getAppVersion (native reads react-native-device-info, web returns pkg.version) and use it where appversion is assembled:

App/src/libs/Network/index.ts

Lines 51 to 56 in 3ad48ca

	shouldRetry: data?.shouldRetry ?? true,
	canCancel: data?.canCancel ?? true,
	appversion: pkg.version,
	};
	// Add promise handlers to any request that we are not persisting

appversion: getAppVersion(),

Because the shell version stays current across bundle swaps, a stale JS bundle can no longer send an outdated appversion, so the backend stops returning a false 426.

2. Add defensive logging in the 426 branch of HttpUtils.ts so any remaining occurrence is diagnosable, capturing the version actually sent alongside pkg.version:

App/src/libs/HttpUtils.ts

Lines 195 to 199 in 3ad48ca

	if (response.jsonCode === CONST.JSON_CODE.UPDATE_REQUIRED) {
	// Trigger a modal and disable the app as the user needs to upgrade to the latest minimum version to continue
	alertUser();
	}
	return response;

if (response.jsonCode === CONST.JSON_CODE.UPDATE_REQUIRED) {
    Log.warn('[UpdateRequired] 426 received', {sentVersion: getAppVersion(), bundleVersion: pkg.version});
    alertUser();
}

This surfaces the shell-vs-bundle mismatch that caused this incident instead of silently blocking the user.

What alternative solutions did you explore? (Optional)

Before calling alertUser(), re-issue a single lightweight authenticated command and only trigger the blocker if it also returns 426. This confirms the version is genuinely below minimum and filters out a one-off transient reconnect, but it adds retry complexity and does not fix the wrong version being sent, so correcting the source version is preferable.

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[KJ21-ENG]

Proposal

What is the root cause of that problem?

The API version being rejected is the NewDot JavaScript bundle version, not an independent native-shell version. The normal request enhancer and queued request path both serialize pkg.version into appversion, so a running bundle from 9.3.91-0 will identify itself as 9.3.91-0 even if the iOS shell around it has already been updated.

App/src/libs/Network/enhanceParameters.ts

Lines 61 to 80 in fec6b33

	if (isAuthTokenRequired(command) && !parameters.authToken) {
	finalParameters.authToken = getAuthToken() ?? null;
	}
	finalParameters.referer = CONFIG.EXPENSIFY.EXPENSIFY_CASH_REFERER;
	// In addition to the referer (ecash), we pass the platform to help differentiate what device type
	// is sending the request.
	finalParameters.platform = getPlatform();
	// This application does not save its authToken in cookies like the classic Expensify app.
	// Setting api_setCookie to false will ensure that the Expensify API doesn't set any cookies
	// and prevents interfering with the cookie authToken that Expensify classic uses.
	finalParameters.api_setCookie = false;
	// Include current user's email in every request and the server logs
	finalParameters.email = parameters.email ?? getCurrentUserEmail();
	finalParameters.isFromDevEnv = Environment.isDevelopment();
	finalParameters.appversion = pkg.version;

App/src/libs/Network/index.ts

Lines 35 to 54 in fec6b33

	/**
	* Perform a queued post request
	*/
	function post<TKey extends OnyxKey>(command: string, data: Record<string, unknown> = {}, type = CONST.NETWORK.METHOD.POST, shouldUseSecure = false): Promise<Response<TKey>> {
	return new Promise((resolve, reject) => {
	const request: Request<never> = {
	command,
	data,
	type,
	shouldUseSecure,
	};
	// By default, request are retry-able and cancellable
	// (e.g. any requests currently happening when the user logs out are cancelled)
	request.data = {
	...data,
	shouldRetry: data?.shouldRetry ?? true,
	canCancel: data?.canCancel ?? true,
	appversion: pkg.version,
	};

On app resume, the authenticated startup flow can send ReconnectApp, which then goes through the same API/version path. If HybridApp keeps an older NewDot startup artifact alive after a native TestFlight update, that stale version reaches the backend before the current bundle/version has been selected.

App/src/libs/Navigation/AppNavigator/AuthScreensInitHandler.tsx

Lines 141 to 155 in fec6b33

	// or returning from background. If so, we'll assume they have some app data already and we can call reconnectApp() instead of openApp().
	// Delegator connect() is handled by DelegatorConnectGate.
	if (delegatorEmail) {
	// connect() handled by DelegatorConnectGate
	} else if (SessionUtils.didUserLogInDuringSession()) {
	const reportID = getReportIDFromLink(initialURL ?? null);
	if (reportID && !isAuthenticatedAtStartup) {
	Report.openReport({reportID, introSelected, betas});
	// Don't want to call `openReport` again when logging out and then logging in
	setIsAuthenticatedAtStartup(true);
	}
	App.openApp();
	} else {
	Log.info('[AuthScreens] Sending ReconnectApp');
	App.reconnectApp(initialLastUpdateIDAppliedToClient);

The App-side blocker after that is expected behavior: any 426 response calls alertUser(), alertUser() sets RAM_ONLY_UPDATE_REQUIRED, Expensify throws the update-required error while that flag is true, and the key is RAM-only, so a hard process restart clears it.

App/src/libs/HttpUtils.ts

Lines 185 to 188 in fec6b33

	if (response.jsonCode === CONST.JSON_CODE.UPDATE_REQUIRED) {
	// Trigger a modal and disable the app as the user needs to upgrade to the latest minimum version to continue
	alertUser();
	}

App/src/libs/actions/UpdateRequired.ts

Lines 5 to 6 in fec6b33

	function alertUser() {
	Onyx.set(ONYXKEYS.RAM_ONLY_UPDATE_REQUIRED, true);

App/src/Expensify.tsx

Line 65 in fec6b33

const [updateRequired] = useOnyx(ONYXKEYS.RAM_ONLY_UPDATE_REQUIRED);

App/src/Expensify.tsx

Lines 281 to 282 in fec6b33

	if (updateRequired) {
	throw new Error(CONST.ERROR.UPDATE_REQUIRED);

App/src/setup/index.ts

Lines 63 to 70 in fec6b33

	ramOnlyKeys: [
	ONYXKEYS.RAM_ONLY_ARE_TRANSLATIONS_LOADING,
	ONYXKEYS.RAM_ONLY_MOBILE_SELECTION_MODE,
	ONYXKEYS.RAM_ONLY_IS_SIDEBAR_LOADED,
	ONYXKEYS.DERIVED.RAM_ONLY_SORTED_REPORT_ACTIONS,
	ONYXKEYS.RAM_ONLY_IS_CHECKING_PUBLIC_ROOM,
	ONYXKEYS.RAM_ONLY_UPDATE_AVAILABLE,
	ONYXKEYS.RAM_ONLY_UPDATE_REQUIRED,

The root cause is therefore the HybridApp/native startup lifecycle allowing stale NewDot startup state to survive a native update, not that App should report the native binary version as appversion. The HybridApp docs explain that HybridApp native code and most HybridApp caches live under Mobile-Expensify, so changing standalone ios/ code in this repo would not fix the HybridApp cache that selected the stale startup state.

App/contributingGuides/HYBRID_APP.md

Lines 8 to 10 in fec6b33

	If you have access to the closed-source `Mobile-Expensify` repository, you are eligible to build HybridApp. The main difference between NewDot and HybridApp is that the native code is located in a different place. The native code is located under `./Mobile-Expensify/Android` and `./Mobile-Expensify/iOS`.
	It is vital to understand, that modifying any code in `./android` and `./ios` folders in the root of the project **will not affect the HybridApp build at all.** In this case, if you'd like to change native code, you have to go to `./Mobile-Expensify/Android` and `./Mobile-Expensify/iOS` first. This is **especially important** when you want to remove native cache or `Pods` manually.

App/contributingGuides/HYBRID_APP.md

Lines 47 to 48 in fec6b33

	The scripts will also remove some deeper hidden cache, but crucial thing to understand is that cache for HybridApp are *mostly* located in `Mobile-Expensify` submodule, alongside the native code.
	As the final step in both standalone and HybridApp scenarios, it runs `npm ci` (clean install), so an explicit `node_modules` installation is not necessary after cleaning.

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

Fix the HybridApp startup/update lifecycle so a native app update cannot resume with an older NewDot bundle or older cached authenticated-startup request metadata. On HybridApp launch/resume, before ReconnectApp, token refresh, or any native prefetch/startup request can run, compare the selected NewDot artifact version/build hash against the current native-packaged NewDot version or the native version metadata stored from the previous launch. If they do not match after a native update, clear the cached NewDot artifact and any cached startup request payload that contains the old appversion, then reload the current packaged NewDot bundle before authenticated requests are allowed to continue.

If the mismatch is detected from JS after startup, expose a small HybridApp bridge method that asks native to discard the stale HybridApp startup artifact and restart NewDot with the current one. The bridge is already the layer used to expose HybridApp-specific native actions to JS.

App/modules/hybrid-app/src/NativeReactNativeHybridApp.ts

Lines 6 to 20 in fec6b33

	export interface Spec extends TurboModule {
	isHybridApp: () => boolean;
	shouldUseStaging: (isStaging: boolean) => void;
	closeReactNativeApp: (shouldSetNVP: boolean) => void;
	completeOnboarding: (status: boolean) => void;
	switchAccount: (newDotCurrentAccountEmail: string, authToken: string, policyID: string, accountID: string) => void;
	sendAuthToken: (authToken: string) => void;
	getHybridAppSettings: () => Promise<string | null>;
	getInitialURL(): Promise<string | null>;
	onURLListenerAdded: () => void;
	signInToOldDot: (autoGeneratedLogin: string, autoGeneratedPassword: string, authToken: string, email: string, policyID: string, signingInWithSAML?: boolean) => void;
	signOutFromOldDot: () => void;
	startSignOut: () => void;
	cancelSignOut: () => void;
	clearOldDotAfterSignOut: () => void;

Keep API appversion tied to the JS bundle that is actually making the request. The backend minimum-version gate should continue to block genuinely stale frontend code; the fix is to stop HybridApp from selecting stale startup state, not to let old frontend code report the newer native shell version.

App/src/libs/Network/enhanceParameters.ts

Lines 61 to 80 in fec6b33

	if (isAuthTokenRequired(command) && !parameters.authToken) {
	finalParameters.authToken = getAuthToken() ?? null;
	}
	finalParameters.referer = CONFIG.EXPENSIFY.EXPENSIFY_CASH_REFERER;
	// In addition to the referer (ecash), we pass the platform to help differentiate what device type
	// is sending the request.
	finalParameters.platform = getPlatform();
	// This application does not save its authToken in cookies like the classic Expensify app.
	// Setting api_setCookie to false will ensure that the Expensify API doesn't set any cookies
	// and prevents interfering with the cookie authToken that Expensify classic uses.
	finalParameters.api_setCookie = false;
	// Include current user's email in every request and the server logs
	finalParameters.email = parameters.email ?? getCurrentUserEmail();
	finalParameters.isFromDevEnv = Environment.isDevelopment();
	finalParameters.appversion = pkg.version;

Add diagnostic logging for any mismatch, including platform, CONFIG.IS_HYBRID_APP, native shell version, JS bundle version, selected bundle/source, and whether a cached startup request payload was cleared. That makes future occurrences diagnosable without weakening the forced-update gate.

Test coverage:

• Add HybridApp/native coverage for installing or resuming a newer iOS shell while an older NewDot startup artifact is cached, verifying the stale artifact and stale appversion request payload are cleared before ReconnectApp or token refresh can run.
• Add coverage for mismatch logging with native version, JS bundle version, selected source, platform, and HybridApp flag.
• Keep or add App-side request tests proving native API metadata still reflects the running JS bundle version, and add a 426 test confirming truly outdated JS still sets RAM_ONLY_UPDATE_REQUIRED.
• Manually verify the TestFlight-style path: install an older HybridApp build, update to a current build, resume without relying on a hard quit, and confirm the Update Required screen does not appear and requests carry the current bundle version.

What alternative solutions did you explore? (Optional)

Using the installed native binary version as API appversion would avoid this one false 426, but it would also let a stale JS bundle bypass the backend minimum-version gate. That hides the real mismatch and can leave old frontend code talking to APIs that expect a newer bundle.

Clearing RAM_ONLY_UPDATE_REQUIRED after a later successful request would only recover after the stale startup state has already sent a bad request. It can be useful as a separate defensive follow-up, but it does not fix the source of this issue.

[github-actions]

⚠️ @KJ21-ENG Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.