Google sign-in takes three client IDs, and the one that breaks on Android is tied to a signature.

Which client IDs do you need, and why are there three?

Start with the Android client, because it is the one with conditions. Google's Android authorisation guide tells you to create an Android type client and specify your app's package name and SHA-1 signature. The package name is the value defined in the package attribute of the manifest element in your AndroidManifest.xml. The fingerprint is the SHA-1 signing certificate fingerprint of the app distribution, which is a phrase worth reading twice: it is about the copy people install, not the copy you built.

The iOS client is simpler and asks for different things. Google wants the bundle identifier as listed in the app's property list file, a ten character Team ID if you are enabling App Check, and optionally your App Store ID. On the device, the GoogleSignIn SDK reads the client ID from a GIDClientID key in Info.plist, and you add the reversed client ID as a CFBundleURLSchemes entry so the browser can hand the result back. Reversed means the dot separated fields in the other order, so a client ID becomes something that starts with com.googleusercontent.apps.

The third client is the one people skip and then spend an afternoon on. It is a Web application type client, and Google describes it as the client ID used to identify your backend server when it communicates with Google's authentication services. The authorised JavaScript origins and redirect URI fields can stay empty if no website is involved. You then hand that same string to both apps. On iOS it is a GIDServerClientID key in Info.plist. On Android, Credential Manager takes it as serverClientId, and Google's implementation guide is explicit that the value is the Web client ID rather than the Android one. Getting those two mixed up produces a token your server politely refuses.

So the honest answer to why there are three is that they answer three different questions. The Android and iOS clients answer which app is calling, and they have to be bound to something unforgeable because no secret is available to them. The Web application client answers which backend the resulting token is meant for, and that question only has one correct answer per project. If your app has no server at all, you do not need the third one, but then you probably do not need sign-in either.

Android Developers, authorize access to Google user data, read 10 October 2026

Why does Google sign-in work in testing and fail on Google Play?

Because the app your testers installed from the store is not signed by the key you signed it with. Play App Signing, which Google calls a requirement when using Android App Bundle, means Google Play holds the app signing key and re-signs the binary it distributes. You sign with an upload key, Google verifies that, strips it and signs with the real one. Google's client authentication guide says the consequence plainly: when using Play App Signing, the upload key certificate will be different than the app signing key certificate.

Now put that next to what the Android OAuth client is bound to. It carries one or more SHA-1 fingerprints, and Google only trusts a caller whose package name and certificate match. Sign-in therefore works on your debug build, works on the APK you sideload, and fails on the copy from the store, with nothing in your code having changed. The error you see at the call site is usually unhelpful and says nothing about certificates, which is why this costs people a day rather than a minute.

The fix is to register every fingerprint rather than one. Google says that if your app uses app signing by Google Play, you copy the SHA-1 fingerprint from the app signing page of the Play Console, which today sits under Release, then Setup, then App integrity. For a keystore you manage, keytool prints it: keytool -list -v -alias your-key-name -keystore path-to-production-keystore. The debug keystore is the same command with the alias androiddebugkey against ~/.android/debug.keystore, where the password is android. Running ./gradlew signingReport dumps the fingerprints for every variant in one go, which is the fastest way to find the one you forgot.

Two habits stop it recurring. Register the Play app signing fingerprint on the day you first upload a bundle, before anyone tests from a track, rather than after the first bug report. And treat a cloud build service as another signing key, because it is one: a build produced on a server is signed by whatever credentials that server holds, so its fingerprint goes on the list too. Expo says the same thing in its own Google authentication guide, telling you to register both the fingerprint of the APK you built and the fingerprint of the production app downloaded from the store.

Android Developers, where to get the SHA-1 when Google Play signs your app, read 10 October 2026

Does adding Google sign-in oblige you to add Apple's?

Nearly, and the difference matters. App Review guideline 4.8 does not name Sign in with Apple at all. It says that an app using a third-party or social login service to set up or authenticate the user's primary account must also offer, as an equivalent option, another login service with three features. It limits data collection to the user's name and email address. It lets users keep their email address private as part of setting up their account. And it does not collect interactions with your app for advertising purposes without consent. Google Sign-In is one of the services Apple lists as triggering the rule.

So the obligation is about properties, not about a brand. Apple defines a primary account as the one users establish with your app to identify themselves, sign in and reach your features. If the Google button is the only way in, you have a 4.8 problem on iOS. Sign in with Apple is the option most teams add, because its private email relay covers the second bullet without any work on your side. Anything else you pick has to clear the same three bars, and the burden of showing that it does falls on you at review time.

There are five written exceptions, and they are narrower than people hope. No second service is required if your app exclusively uses your own company's account setup and sign-in systems. Or if it is an alternative app marketplace, or an app distributed from one, using a marketplace specific login. Or if it is an education, enterprise or business app that requires an existing education or enterprise account. Or if it uses a government or industry-backed citizen identification system or electronic ID. Or if it is a client for a specific third-party service and users must sign in to that account directly to reach their own content.

The practical reading is that Google sign-in is rarely a standalone decision on iOS. Plan for two buttons and a single account record behind them, because the same person will sign in with Google on Android and with Apple on their iPad and expect one account. That is a data model question rather than an SDK question, and it is cheaper to answer on day one than after the first support ticket.

Apple, App Review Guidelines, 4.8 Login Services, read 10 October 2026

What does your server have to do with the token?

Verify it, and check who it was issued for. A successful sign-in hands your app an ID token, a signed statement from Google about who just authenticated. Your backend has to validate it before it believes anything inside, and one of the required checks is the audience. Google's wording is that the value of aud in the ID token is equal to one of your app's client IDs, and that this check is necessary to prevent ID tokens issued to a malicious app being used to access data about the same user on your app's backend server. That is the whole reason the Web application client ID exists as a separate thing.

The tempting shortcut is the one Google warns about by name. Do not accept plain user IDs on your backend server, it says, because a modified client application can send arbitrary user IDs to your server to impersonate users. Anyone can post a string. Only Google can sign a token. So the client sends the token, the server verifies the signature, the issuer, the expiry and the audience, and only then looks up or creates the account. Credential Manager also supports a nonce you generate per request, which closes the replay gap on Android.

One more thing to know before you build on the old examples. The legacy library is on the way out. Google's migration page says Google Sign-In for Android, as part of com.google.android.gms:play-services-auth, is deprecated and will be removed from the Google Play services Auth SDK in a future release, and the legacy guide now warns that the API is outdated and no longer supported. Credential Manager is the current path. It gives you two surfaces, a dismissible bottom sheet and a persistent Sign in with Google button, and Google points out that the button lets people restart the flow without restarting the app and can add an account the device does not have yet. Both take your Web application client ID as serverClientId. No removal date has been published, so there is no emergency, only a wrong thing to start from. If you are choosing between providers rather than wiring one up, the broader shape of app authentication is the better place to decide.

And decide early whether Google is the front door or an extra key. An app with an email and password route already has an account record, a password reset flow and a support story, and Google becomes one more way into it. An app where Google is the only route inherits Google's account recovery and loses anyone who signs in with a work address they later leave. Adding plain user login first and social providers second is usually the cheaper order, because the hard part was never the button.