How to add Google sign-in to your app

Your app authenticates its users against your own Supabase project — the one the agent created or connected for you. Vibely is not in that flow and has no auth settings of its own for your users. That matters, because it splits the job in two:

Half	Where it happens
The sign-in screen, the supabase.auth calls, session handling	Ask the agent in chat
Turning Google on, and its client ID and secret	Your Supabase dashboard → Authentication → Providers
The URLs Google is allowed to send users back to	Your Supabase dashboard → Authentication → URL Configuration

The agent cannot enable the provider for you. That step lives behind your own credentials with Google, in your own dashboard.

Step 1 — ask for the UI

"Add sign in with Google, a signed-out landing state, and protect the dashboard route." The agent writes the screens, the auth calls and the session handling.

Step 2 — enable the provider in Supabase

In your Supabase dashboard, Authentication → Providers → Google. It needs a Google Cloud OAuth client. Supabase's own Google setup guide is the current one; we deliberately do not copy those steps here, because Google's console changes and copies rot.

Step 3 — the two URLs (this is the step that breaks)

Every redirect flow — OAuth, magic link, email confirmation, password reset — sends the user out and back. Supabase only completes the round trip if the return URL is on its allowlist, and your app has two hostnames:

URL	What it is	Who can load it
<short-id>.vibelyagent.com	The sandbox preview, live as soon as the project is	You only, through the Vibely app
<your-slug>.vibelyagent.com or your custom domain	The published app	Your users

Add both under Authentication → URL Configuration, and set Site URL to the published one. Site URL is the fallback Supabase uses when a flow carries no explicit redirect — most importantly the link inside a confirmation email. Point it at the preview and your users receive confirmation emails that land on a URL only you can open.

Add your custom domain to that list the day it verifies, not the day sign-in breaks.

On a phone, the return trip is different

There is no page to redirect to on native. iOS opens ASWebAuthenticationSession and Android opens a Custom Tab; the system hands control back through a custom URL scheme like myapp://auth-callback. Ask for social sign-in in a mobile project and the agent installs expo-auth-session and expo-web-browser (neither ships in the starter) and writes the flow. Three details do the work, and all three are easy to get wrong by hand:

• skipBrowserRedirect: true on signInWithOAuth — you want the URL, not a navigation in a browser that does not exist here.
• The redirect string you pass to openAuthSessionAsync must be byte-identical to the one you sent Supabase, or the sheet never closes.
• setSession — nothing on native detects the callback URL for you. Until you call it, the user is not signed in and nothing is persisted.

Sessions are stored in the Keychain on iOS and the Android Keystore, already wired.

One App Store rule you cannot skip

If your iOS app offers Google sign-in — or Facebook, or X — Guideline 4.8 requires an equivalent option that limits data collection to name and email, lets the user hide their email address, and does not feed advertising. In practice that means Sign in with Apple, and email-and-password does not satisfy it. Add it in the same turn, not after a rejection. See publishing to the App Store.

Before you launch: your own SMTP

A new Supabase project sends auth email through a shared SMTP service with a low hourly rate limit, meant for testing. Set your own under Project Settings → Authentication → SMTP Settings before launch, or confirmation emails quietly stop arriving under real signup volume.