[$250] Bug: Can't sign in via Google auth on iPhone (staging)

[melvin-bot]

Bug Report

Reproducible in staging?: Yes
Reproducible in production?: Unknown

Description:
Users are unable to sign in via Google authentication on iPhone in the staging environment. The issue has been reproduced by multiple testers and is intermittent — some testers could not reproduce it on the latest staging TestFlight build, while others (including internal engineers) confirmed it still occurs.

Steps to reproduce:

1. Open the New Expensify app on iPhone (latest staging TestFlight build)
2. Tap "Sign in with Google"
3. Observe that sign-in fails or does not complete

Expected result: User is successfully signed in via Google auth.
Actual result: Sign-in via Google auth fails on iPhone in staging.

Reported by: grgia, mountiny
Slack thread: (internal)

Upwork Automation - Do Not Edit

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

[melvin-bot]

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

[godzillaxbox19982014-lgtm]

Proposal

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

Bug: Can't sign in via Google auth on iPhone (staging)

What is the root cause of that problem?

I traced this to the path that handles TestFlight:

• src/libs/Navigation/AppNavigator/Navigators/MultifactorAuthenticationModalNavigator.tsx:39 (Stack): const Stack = createPlatformStackNavigator<MultifactorAuthenticationModalNavigatorInternalParamList>();
• src/pages/signin/SignInModal.tsx:46 (isAnonymousUser): const isAnonymousUser = session?.authTokenType === CONST.AUTH_TOKEN_TYPES.ANONYMOUS;
• src/pages/signin/SAMLSignInPage/index.native.tsx:70 (if): if (!account?.isLoading && credentials?.login && shortLivedAuthToken) {
• The local evidence matches this recurring failure shape: domain/account lookup errors are mapped to generic failure text. Here, src/libs/Navigation/AppNavigator/Navigators/MultifactorAuthenticationModalNavigator.tsx:39 and src/pages/signin/SignInModal.tsx:46 do not agree on the same TestFlight value, so the user-visible path can show a missing or stale state even though nearby data already has the needed context.

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

• Update src/libs/Navigation/AppNavigator/Navigators/MultifactorAuthenticationModalNavigator.tsx:39 to derive TestFlight from the auth/onboarding state that owns this flow before the value is consumed.
• Carry the same normalized value through src/pages/signin/SignInModal.tsx:46; that follows the safer family move to map the API error to the user-facing translation at the action boundary, so the write/optimistic/read paths agree instead of only changing the visible component.
• Keep the change inside the Auth, Login, Onboarding, Account Details surface and avoid changing account/login flows, auth tokens.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

1. Add or update a regression in tests/unit/Session*.ts for the exact issue flow: Bug: Can't sign in via Google auth on iPhone (staging).
2. Cover the counter-case near src/libs/Navigation/AppNavigator/Navigators/MultifactorAuthenticationModalNavigator.tsx:39 so valid existing TestFlight behavior still works.
3. Manually repeat the issue steps after the patch and confirm the visible state/action is no longer stale.

What alternative solutions did you explore? (Optional)

• I would not add a broad new condition outside these referenced paths; the safer fix is to keep TestFlight consistent at the first read/write boundary shown above.

[melvin-bot]

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

[shivang-goliyan]

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

Proposal

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

On the staging TestFlight build for iPhone, tapping "Sign in with Google" sometimes fails to complete the sign-in. It's intermittent: some testers can't reproduce it on the latest build, others (including internal engineers) still hit it. Web, mWeb, and MacOS are unaffected.

What is the root cause of that problem?

The Google flow on native goes BaseLoginForm → googleSignInRequest() in src/components/SignInButtons/GoogleSignIn/index.native.tsx → GoogleSignin.configure() → GoogleSignin.signIn() → .then((response) => response.idToken) → beginGoogleSignIn(token, locale) (src/libs/actions/Session/index.ts) → API.write(SIGN_IN_WITH_GOOGLE, ...). I checked the obvious JS suspects first and they hold up: package-lock pins @react-native-google-signin/google-signin at 10.0.1, where signIn() resolves a top-level idToken, so response.idToken at index.native.tsx:48 is correct (the {type, data:{idToken}} breaking change is v13). git log on this file shows no logic change since 2025 — the only 2026-07-02 touch is Oxfmt formatting — so this isn't an App-side regression.

Given staging-only, intermittent, and "fixed on some builds," the most probable cause is the native iOS OAuth configuration for the HybridApp build, not App JS. Staging runs the HybridApp binary, which uses iosClientId = 1008697809946-sh04nqq0hea396s1qdqqbj6ia649odb2 (src/CONFIG.ts:125). For that client, iOS success requires the Info.plist to register the URL scheme com.googleusercontent.apps.1008697809946-sh04nqq0hea396s1qdqqbj6ia649odb2 and a valid iOS OAuth client for project 1008697809946. That Info.plist lives in the Mobile-Expensify submodule, and this kind of "works on some devices/builds" pattern is what you get from a missing or renamed reversed-client-id scheme, an unregistered staging bundle ID, or Google-side propagation lag. If that's it, the fix is in Mobile-Expensify / Google Cloud Console, not this repo.

There is one real in-scope robustness gap worth noting either way: at index.native.tsx:45 the pre-sign-in GoogleSignin.signOut() is fired without await, so signIn() can start before signOut settles, which is exactly the kind of ordering that surfaces intermittently. And at line 49, if signIn() ever resolves without an idToken, we call beginGoogleSignIn(undefined) and send a null token to Auth, which comes back as a generic failure instead of something diagnosable.

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

First, confirm on a physical iPhone staging build where it actually breaks, using the existing Log.alert output in the .catch. If the failure is inside native GoogleSignin.signIn() (URL-scheme / OAuth), it's a Mobile-Expensify + Google Cloud fix and out of scope for this repo — worth saying so plainly rather than shipping an App patch that can't touch the cause.

If the repro points at the JS path, two small changes in index.native.tsx make the flow correct and its failures legible: await GoogleSignin.signOut() before signIn() so the two calls can't overlap, and guard the token before beginGoogleSignIn so a missing idToken fails fast with a clear log instead of sending null to the backend. Both are minimal and don't change the happy path.

What alternative solutions did you explore? (Optional)

I considered a client-ID mismatch (standalone 921154746561… iosClientId used against the hybrid Info.plist) — plausible, but IS_HYBRID_APP selects the hybrid IDs correctly in CONFIG.ts, and confirming it still requires reading the native Info.plist. I also considered the response.idToken shape, but that would fail 100% of the time and contradicts the reported intermittency. There's no unit coverage for googleSignInRequest; a test can cover the null-token guard but can't reproduce a native OAuth failure, so device testing is the deciding step here.

[mukhrr]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-03 11:56:32 UTC.

Proposal

What is the root cause of that problem?

The native iOS Google sign-in config is not fully environment/bundle aware for the staging iPhone build.

GoogleSignin.configure() chooses the iOS OAuth client from CONFIG.IS_HYBRID_APP only:

App/src/components/SignInButtons/GoogleSignIn/index.native.tsx

Lines 35 to 39 in c8d6035

	function googleSignInRequest(preferredLocale?: Locale) {
	GoogleSignin.configure({
	webClientId: getWebClientId(),
	iosClientId: CONFIG.IS_HYBRID_APP ? CONFIG.GOOGLE_SIGN_IN.HYBRID_APP.IOS_CLIENT_ID : CONFIG.GOOGLE_SIGN_IN.IOS_CLIENT_ID,
	offlineAccess: false,

For the non-hybrid iOS path it always uses the production iOS client:

App/src/CONFIG.ts

Lines 118 to 131 in c8d6035

	GOOGLE_SIGN_IN: {
	// cspell:disable-next-line
	WEB_CLIENT_ID: '921154746561-gpsoaqgqfuqrfsjdf8l7vohfkfj7b9up.apps.googleusercontent.com',
	// cspell:disable-next-line
	IOS_CLIENT_ID: '921154746561-s3uqn2oe4m85tufi6mqflbfbuajrm2i3.apps.googleusercontent.com',
	HYBRID_APP: {
	// cspell:disable-next-line
	IOS_CLIENT_ID: '1008697809946-sh04nqq0hea396s1qdqqbj6ia649odb2.apps.googleusercontent.com',
	WEB_CLIENT_ID: {
	// cspell:disable-next-line
	IOS: '1008697809946-5e095eqem3o6ugtpc2rjf7v880tcp28p.apps.googleusercontent.com',
	// cspell:disable-next-line
	ANDROID: '240677659774-86pov3adub93cv4b8uj13g7varolmk2l.apps.googleusercontent.com',
	},

But the staging/dev iOS app target uses the com.expensify.chat.dev bundle ID:

App/ios/NewExpensify.xcodeproj/project.pbxproj

Lines 1086 to 1088 in c8d6035

	OTHER_SWIFT_FLAGS = "$(inherited) -D EXPO_CONFIGURATION_DEBUG";
	PRODUCT_BUNDLE_IDENTIFIER = com.expensify.chat.dev;
	PRODUCT_NAME = "New Expensify Dev";

and has a different DEV Google iOS client / reversed client ID:

App/ios/GoogleService-Info-DEV.plist

Lines 5 to 8 in c8d6035

	<key>CLIENT_ID</key>
	<string>921154746561-8niu5ba8g4dgsqsqso3lugdhe6vikqpq.apps.googleusercontent.com</string>
	<key>REVERSED_CLIENT_ID</key>
	<string>com.googleusercontent.apps.921154746561-8niu5ba8g4dgsqsqso3lugdhe6vikqpq</string>

The production plist uses the client currently hardcoded in CONFIG.ts:

App/ios/GoogleService-Info.plist

Lines 5 to 8 in c8d6035

	<key>CLIENT_ID</key>
	<string>921154746561-s3uqn2oe4m85tufi6mqflbfbuajrm2i3.apps.googleusercontent.com</string>
	<key>REVERSED_CLIENT_ID</key>
	<string>com.googleusercontent.apps.921154746561-s3uqn2oe4m85tufi6mqflbfbuajrm2i3</string>

Also, Info.plist registers only the production reversed client URL scheme:

App/ios/NewExpensify/Info.plist

Lines 37 to 43 in c8d6035

	<dict>
	<key>CFBundleTypeRole</key>
	<string>Editor</string>
	<key>CFBundleURLSchemes</key>
	<array>
	<string>com.googleusercontent.apps.921154746561-s3uqn2oe4m85tufi6mqflbfbuajrm2i3</string>
	</array>

So on staging iPhone, the app can launch Google Sign-In with an iOS OAuth client / callback scheme that does not match the installed app bundle. Google iOS OAuth clients are tied to the bundle/callback configuration, so the SDK can fail before we receive an idToken, and beginGoogleSignIn() never gets a valid token to complete sign-in.

This same class of bug already happened in this flow. Commit cd7ef32a648 changed the Google sign-in config for HybridApp, but only changed webClientId. The next commit, 0d82833afd3, was explicitly titled Fix iOS client ID on HybridApp and changed iosClientId to be host-specific too:

0d82833

There is also a similar native auth regression in #58679 where Apple Sign-In failed because the auth redirect config did not match the environment. The accepted fix there was to normalize the environment-specific auth URL config instead of changing UI behavior:

#58679 (comment)

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

Make the native iOS Google Sign-In config choose the iOS client and URL scheme from the actual iOS build environment/bundle, not only from CONFIG.IS_HYBRID_APP.

Small illustrative diff:

 GOOGLE_SIGN_IN: {
     WEB_CLIENT_ID: '921154746561-gpsoaqgqfuqrfsjdf8l7vohfkfj7b9up.apps.googleusercontent.com',
     IOS_CLIENT_ID: '921154746561-s3uqn2oe4m85tufi6mqflbfbuajrm2i3.apps.googleusercontent.com',
+    IOS_CLIENT_ID_DEV: '921154746561-8niu5ba8g4dgsqsqso3lugdhe6vikqpq.apps.googleusercontent.com',
     HYBRID_APP: {
         IOS_CLIENT_ID: '1008697809946-sh04nqq0hea396s1qdqqbj6ia649odb2.apps.googleusercontent.com',

+function getIOSClientId() {
+    if (CONFIG.IS_HYBRID_APP) {
+        return CONFIG.GOOGLE_SIGN_IN.HYBRID_APP.IOS_CLIENT_ID;
+    }
+
+    return CONFIG.ENVIRONMENT === CONST.ENVIRONMENT.DEV
+        ? CONFIG.GOOGLE_SIGN_IN.IOS_CLIENT_ID_DEV
+        : CONFIG.GOOGLE_SIGN_IN.IOS_CLIENT_ID;
+}

 GoogleSignin.configure({
     webClientId: getWebClientId(),
-    iosClientId: CONFIG.IS_HYBRID_APP ? CONFIG.GOOGLE_SIGN_IN.HYBRID_APP.IOS_CLIENT_ID : CONFIG.GOOGLE_SIGN_IN.IOS_CLIENT_ID,
+    iosClientId: getIOSClientId(),
     offlineAccess: false,
 });

Also update the iOS URL scheme configuration so the dev/staging iOS build registers the DEV reversed client ID from GoogleService-Info-DEV.plist, while production keeps the current production reversed client ID.

To avoid regressions:

• Keep production defaulting to the existing production IOS_CLIENT_ID.
• Keep HybridApp defaulting to the existing HYBRID_APP.IOS_CLIENT_ID, since that was added by the previous Fix iOS client ID on HybridApp commit.
• Only route the dev/staging standalone iOS build to the DEV client/scheme.
• Verify Google sign-in on iOS staging/TestFlight, iOS production, and HybridApp.
• Add a focused test around the helper selecting the correct client ID for production, dev/staging, and HybridApp.

What alternative solutions did you explore? (Optional)

Only changing iosClientId in JS is not enough because iOS also needs the matching reversed client URL scheme for the OAuth callback. I also would not change the backend SIGN_IN_WITH_GOOGLE call, because the failure happens before we reliably receive an idToken.

[MelvinBot]

⚠️ Preliminary analysis (low–medium confidence) — the client-side code path is in the public App repo, but confirming this specific intermittent staging failure needs device/native logs, which aren't available from this report. Treat as a starting point.

Issue Analysis

Most likely in-repo cause: In the native Google sign-in handler, GoogleSignin.signOut() is called un-awaited, immediately followed by GoogleSignin.signIn(). signOut() returns a Promise; because it isn't awaited, signIn() can start while the native session is still being torn down. That race is exactly the kind of thing that produces an intermittent failure that some testers hit and others don't — which matches the report. Per the code comment, this signOut() exists only to force the account chooser on Android, yet it also runs on iPhone, where it adds the race without a clear benefit — consistent with this being iOS-specific.

Recommended direction (to validate, not yet confirmed): await the signOut() before calling signIn() (or skip signOut() on iOS via getPlatform()), so the two native calls can't overlap:

await GoogleSignin.signOut();
const response = await GoogleSignin.signIn();

Before implementing, confirm with a device log. The handler already logs failures at index.native.tsx:53/63 ([Google Sign In] Error Code: …). Grabbing that error code/message from a failing iPhone would either confirm this or point elsewhere.

Alternatives considered & why the existing proposal doesn't fit

The existing proposal does not match this bug. It points at MultifactorAuthenticationModalNavigator, SignInModal, and SAMLSignInPage, and invents an inconsistent "TestFlight value." None of those are on the Google auth path — Google native sign-in lives entirely in src/components/SignInButtons/GoogleSignIn/index.native.tsx → beginGoogleSignIn → the SignInWithGoogle API command. That proposal should be rejected.

Other plausible causes that logs would need to rule in/out (some are outside the App repo):

• idToken audience / client-ID config — the idToken is read from the signIn() response and its aud is tied to the configured webClientId/iosClientId (CONFIG.ts:118-133). If a staging build ships an empty/mismatched client ID, the backend token verification rejects it. This tends to be consistent rather than intermittent, so it's a weaker fit — but a staging-only env/build misconfig is worth checking.
• Native Info.plist URL scheme (reversed client ID) — a build/native concern, not JS; would fail consistently, not intermittently.
• Backend SignInWithGoogle verification — lives in Auth/Web-Expensify, not this repo. If the root cause is there, it needs an internal engineer with access to those repos, not an App-side fix.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/95273#issuecomment-4875829971) to create a draft PR.
To refine: @MelvinBot <your feedback> (e.g. paste the [Google Sign In] Error Code from a failing iPhone and I'll narrow it down).
To reject: Explain why you are rejecting Melvin's proposal.