Adding Google Sign-In to an App That Isn't Even Published Yet

Adding Google Sign-In sounded like one of those features that should be simple: add a button, open Google, get the user back into the app and save their account. In practice, the interesting part was not the button at all. It was understanding that authentication involves several systems agreeing on the identity of the same application.

I was working on an Expo/React Native app with Firebase and wanted users to be able to sign in with Google before the app was anywhere near the App Store. At first that felt slightly strange. How do you configure authentication for an application that is still running locally on my phone?

The answer is that the app does not need to be publicly released. It just needs an identity that Google and Firebase can recognise.

The app needs an identity before it has users

With Google authentication, there are several pieces involved. Firebase needs Google enabled as a sign-in provider, Google needs OAuth credentials for the application, and the mobile app needs the correct configuration so that the login result comes back to the right place.

This was useful for me because it made OAuth feel much less mysterious. The basic idea is not “Google somehow logs the user into my app”. My application asks Google to authenticate someone, Google returns proof of who that person is, and Firebase uses that result to create or identify the corresponding user in my application.

The application can still be in development while all of this happens.

What matters are things such as the app identifier, OAuth client configuration and the redirect path used during the authentication flow.

Most authentication problems are configuration problems

The code for the button itself was not especially difficult. The annoying part was making sure all of the configuration matched.

If one system thinks the application has one identifier and another is configured for something slightly different, authentication can fail even though the code looks perfectly reasonable. The same is true for redirect URLs and development builds: the login provider has to know where it is allowed to send the user after authentication.

This is also where mobile development starts exposing the difference between a normal web application and an installed app. On the web, returning to a URL feels natural. On mobile, the application needs its own way of being opened again after the external authentication screen finishes.

Once I understood that, debugging became much easier. Instead of repeatedly changing the login code, I could check the chain of configuration: is Google enabled, are the OAuth credentials correct, is this the right app identifier, and can the authentication flow return to this build?

You can build the real account system before release

The part I liked most was that this did not have to be a temporary fake login just because the app was unfinished.

I could already create real Firebase users, associate application data with them and test the same basic authentication flow that the production version would eventually use. Development accounts are still development accounts, but the architecture does not need to be thrown away later.

That is a recurring lesson I am starting to notice while building apps: “not published yet” does not mean “not real yet”.

You can already have authentication, databases, APIs and backend services working long before the application reaches an app store. The important part is separating development configuration from production configuration so that the transition later does not become a mess.

For a first Google Sign-In integration, I would worry less about the login button and more about understanding the identity flow around it. Once Google, Firebase and the app all agree on what the application is, the actual code becomes the easy part.