Skip to main content

Apple & Google Login with Supabase

This guide walks you through adding Sign in with Apple and Sign in with Google to a Newly app that uses Supabase as its backend. Unlike email/password, social login needs a one-time setup in the provider consoles (Google Cloud, Apple Developer) and in your Supabase Dashboard. Newly can’t do this part for you because it involves your own developer accounts and secrets. Once configured, you tell the AI to build the buttons and wire up the flow.
This guide is for projects using Supabase. If you’re on Liquid Backend, follow Adding Authentication instead — Google login works there without any console setup for development. See Backend Systems to check which backend you’re on.

How social login works on native

On a phone, social login isn’t a website popup — it uses the operating system’s native account picker. The flow is:
  1. The user taps Continue with Apple / Continue with Google.
  2. The OS shows its native sign-in sheet and returns a signed ID token.
  3. Your app passes that token to Supabase with signInWithIdToken.
  4. Supabase verifies the token, creates or finds the user, and returns a session.
This is why each provider needs a client ID that matches your app, and why Supabase needs to know which client IDs to trust.

Prerequisites

Supabase project connected

Your Newly app is already linked to a Supabase project

Apple Developer Account

Required for Sign in with Apple ($99/year)

Google Cloud Account

Free — for creating OAuth client IDs

Your app's Bundle ID

e.g. com.yourcompany.yourapp — you’ll need it in both consoles
Decide your Bundle ID before starting. Both Apple and Google tie their client IDs to it, and changing it later means redoing this setup. See Changing Your Bundle ID.

Sign in with Google

Step 1: Create OAuth client IDs in Google Cloud

Google needs a separate client ID per platform.
1

Create a project

Go to the Google Cloud Console and create (or select) a project.
2

Configure the consent screen

Go to APIs & Services → OAuth consent screen. Choose External, fill in the app name, support email, and developer contact. Add your email as a test user while developing.
3

Create a Web client ID

Under Credentials → Create Credentials → OAuth client ID, choose Web application. This is the client Supabase uses. Copy its Client ID and Client secret.
4

Add the Supabase redirect URL

In the Web client, add this to Authorized redirect URIs (find your project ref in the Supabase Dashboard URL):
5

Create an iOS client ID

Create another OAuth client ID of type iOS and enter your app’s Bundle ID. Copy this iOS Client ID.
6

Create an Android client ID (if shipping Android)

Create an Android OAuth client ID with your package name and SHA-1 certificate fingerprint. Copy the Android Client ID.

Step 2: Enable Google in Supabase

1

Open the provider settings

In the Supabase Dashboard go to Authentication → Providers → Google and toggle it on.
2

Add the Web client credentials

Paste the Web Client ID and Client secret from Step 1.
3

Authorize your native client IDs

In the Authorized Client IDs field, add your iOS (and Android) client IDs, comma-separated. This is what lets Supabase trust the ID tokens coming from the native sign-in sheet.
4

Save

Click Save.
A common mistake is adding only the Web client ID. Native sign-in returns tokens issued to the iOS/Android client IDs — if those aren’t in Authorized Client IDs, Supabase rejects the token with an “audience mismatch” error.

Step 3: Build the button in Newly

Tell the AI what you want, and give it the client IDs so it can configure the native module:
Newly installs and configures the native Google Sign-In package for you. Because this adds a native module, you’ll need to run it on a development build / TestFlight, not the in-editor preview. See Preview vs Builds.

Sign in with Apple

Apple requires native Sign in with Apple for any app that offers third-party login (like Google) on iOS. So if you add Google, you generally must add Apple too, or Apple may reject your submission.

Step 1: Configure your App ID in Apple Developer

1

Enable the capability

In the Apple Developer portal, go to Certificates, Identifiers & Profiles → Identifiers, open your app’s App ID (matching your Bundle ID), and enable the Sign in with Apple capability.
2

Create a Services ID

Create a new Services ID (e.g. com.yourcompany.yourapp.signin). Enable Sign in with Apple on it and configure the web domain and return URL:
3

Create a signing key

Under Keys, create a new key with Sign in with Apple enabled. Download the .p8 file (you can only download it once) and note the Key ID and your Team ID.

Step 2: Enable Apple in Supabase

1

Open the provider settings

Go to Authentication → Providers → Apple in the Supabase Dashboard and toggle it on.
2

Add your credentials

Enter the Services ID (as the Client ID), your Team ID, Key ID, and the contents of the .p8 key file so Supabase can generate the client secret.
3

Authorize the native client ID

In Authorized Client IDs, add your app’s Bundle ID. Native iOS Sign in with Apple issues tokens to the bundle ID, so Supabase needs it listed to accept them.
4

Save

Click Save.

Step 3: Build the button in Newly

Apple only returns the user’s name and email on the first sign-in for a given Apple ID. Capture and store them then — on later logins you’ll only get the user identifier. If you need to test again, remove the app from your Apple ID under Settings → your name → Sign in with Apple.

Handling the session

Once either provider returns a session, the rest of your auth flow is identical to email/password. Ask the AI to tie it together:
Supabase stores the session automatically when the client is configured with persistent storage. Newly sets this up for you, but if sessions don’t persist, tell the AI: “The Supabase session isn’t persisting across app restarts.”

Row Level Security

Social-logged-in users are regular Supabase auth users, so the same RLS rules apply. Make sure your tables restrict rows to the owner:
See Supabase Integration → Row Level Security for common patterns.

Testing

1

Use a development build

Native sign-in needs a real build (TestFlight or dev client), not the in-editor preview.
2

Sign in with Google

Tap the button, pick an account, and confirm you land on the home screen.
3

Sign in with Apple

On a real iOS device or simulator signed into an Apple ID, confirm the sheet appears and login succeeds.
4

Verify the user in Supabase

Check Authentication → Users in the Supabase Dashboard — the new user should appear with the correct provider.
5

Test persistence

Fully close and reopen the app — you should still be signed in.

Troubleshooting

The iOS/Android client ID that issued the token isn’t listed in Supabase. Add it under Authentication → Providers → Google → Authorized Client IDs (comma-separated), separate from the Web client ID.
  • Confirm Sign in with Apple is enabled on your App ID and the Bundle ID matches exactly.
  • Confirm your Bundle ID is in Supabase’s Authorized Client IDs for Apple.
  • Native Sign in with Apple only works on a real build, not the preview.
The redirect URL in Google Cloud (Web client) and Apple’s Services ID must exactly match https://<your-project-ref>.supabase.co/auth/v1/callback. Double-check the project ref.
Apple only sends name/email on the first authorization for that Apple ID. Store them on first login, and remove the app under Settings → Sign in with Apple to test the first-run flow again.
Native sign-in modules only run in real builds. The web browser OAuth flow can run in the preview but gives a worse UX. Use native sign-in for shipping apps. See Preview vs Builds.

Next Steps

Supabase Integration

Full reference for Supabase in Newly

Adding Authentication

Email/password auth and protected routes

Connect a Database

Store user-specific data

Preview vs Builds

Why native login needs a real build