> ## Documentation Index
> Fetch the complete documentation index at: https://docs.newly.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Apple & Google Login with Supabase

> Add Sign in with Apple and Sign in with Google to your app using Supabase Auth

# 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.

<Note>
  This guide is for projects using **Supabase**. If you're on **Liquid Backend**, follow [Adding Authentication](/guides/adding-authentication) instead — Google login works there without any console setup for development. See [Backend Systems](/features/backend) to check which backend you're on.
</Note>

## 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

<CardGroup cols={2}>
  <Card title="Supabase project connected" icon="database" href="/integrations/supabase">
    Your Newly app is already linked to a Supabase project
  </Card>

  <Card title="Apple Developer Account" icon="apple">
    Required for Sign in with Apple (\$99/year)
  </Card>

  <Card title="Google Cloud Account" icon="google">
    Free — for creating OAuth client IDs
  </Card>

  <Card title="Your app's Bundle ID" icon="hashtag" href="/guides/bundle-id-changes">
    e.g. <code>com.yourcompany.yourapp</code> — you'll need it in both consoles
  </Card>
</CardGroup>

<Tip>
  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](/guides/bundle-id-changes).
</Tip>

***

## Sign in with Google

### Step 1: Create OAuth client IDs in Google Cloud

Google needs a separate client ID per platform.

<Steps>
  <Step title="Create a project">
    Go to the [Google Cloud Console](https://console.cloud.google.com) and create (or select) a project.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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**.
  </Step>

  <Step title="Add the Supabase redirect URL">
    In the Web client, add this to **Authorized redirect URIs** (find your project ref in the Supabase Dashboard URL):

    ```
    https://<your-project-ref>.supabase.co/auth/v1/callback
    ```
  </Step>

  <Step title="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**.
  </Step>

  <Step title="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>
</Steps>

### Step 2: Enable Google in Supabase

<Steps>
  <Step title="Open the provider settings">
    In the [Supabase Dashboard](https://supabase.com/dashboard) go to **Authentication → Providers → Google** and toggle it on.
  </Step>

  <Step title="Add the Web client credentials">
    Paste the **Web** Client ID and Client secret from Step 1.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Save">
    Click **Save**.
  </Step>
</Steps>

<Warning>
  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.
</Warning>

### 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:

```
Add a "Continue with Google" button to my Login and Sign Up screens
using native Google Sign-In and Supabase.

Use supabase.auth.signInWithIdToken with the ID token from the native
Google sign-in sheet (not the web browser flow).

My Google iOS client ID is: <paste iOS client ID>
My Google Web client ID is: <paste Web client ID>

Match the existing screen design, show a loading state while signing in,
and navigate to the home screen on success.
```

<Note>
  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](/guides/preview-vs-builds).
</Note>

***

## 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

<Steps>
  <Step title="Enable the capability">
    In the [Apple Developer portal](https://developer.apple.com/account), go to **Certificates, Identifiers & Profiles → Identifiers**, open your app's **App ID** (matching your Bundle ID), and enable the **Sign in with Apple** capability.
  </Step>

  <Step title="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:

    ```
    https://<your-project-ref>.supabase.co/auth/v1/callback
    ```
  </Step>

  <Step title="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>
</Steps>

### Step 2: Enable Apple in Supabase

<Steps>
  <Step title="Open the provider settings">
    Go to **Authentication → Providers → Apple** in the Supabase Dashboard and toggle it on.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Save">
    Click **Save**.
  </Step>
</Steps>

### Step 3: Build the button in Newly

```
Add a "Sign in with Apple" button to my Login and Sign Up screens,
following Apple's Human Interface Guidelines (black button, Apple logo).

Use expo-apple-authentication to get the identity token, then call
supabase.auth.signInWithIdToken with provider "apple".

Only show the button on iOS. Handle the case where the user cancels
the sheet, and navigate to the home screen on success.
```

<Warning>
  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**.
</Warning>

***

## 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:

```
After a successful social login, persist the Supabase session so the user
stays logged in across app restarts, and load their profile.

If a profiles table row doesn't exist for this user yet, create one with
their name and email from the auth session.
```

<Note>
  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."
</Note>

## 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:

```
Add RLS policies so each user can only read and write their own rows,
matching auth.uid() against the user_id column.
```

See [Supabase Integration → Row Level Security](/integrations/supabase#row-level-security) for common patterns.

## Testing

<Steps>
  <Step title="Use a development build">
    Native sign-in needs a real build (TestFlight or dev client), not the in-editor preview.
  </Step>

  <Step title="Sign in with Google">
    Tap the button, pick an account, and confirm you land on the home screen.
  </Step>

  <Step title="Sign in with Apple">
    On a real iOS device or simulator signed into an Apple ID, confirm the sheet appears and login succeeds.
  </Step>

  <Step title="Verify the user in Supabase">
    Check **Authentication → Users** in the Supabase Dashboard — the new user should appear with the correct provider.
  </Step>

  <Step title="Test persistence">
    Fully close and reopen the app — you should still be signed in.
  </Step>
</Steps>

## Troubleshooting

<AccordionGroup>
  <Accordion title="Google: 'audience mismatch' or 'invalid token' error">
    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.
  </Accordion>

  <Accordion title="Apple: button does nothing / 'not handled' error">
    * 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.
  </Accordion>

  <Accordion title="Redirect URI mismatch">
    The redirect URL in Google Cloud (Web client) and Apple's Services ID must exactly match <code>https\://\<your-project-ref>.supabase.co/auth/v1/callback</code>. Double-check the project ref.
  </Accordion>

  <Accordion title="Apple approves but returns no email">
    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.
  </Accordion>

  <Accordion title="Works in preview but not in the build (or vice versa)">
    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](/guides/preview-vs-builds).
  </Accordion>
</AccordionGroup>

## Next Steps

<CardGroup cols={2}>
  <Card title="Supabase Integration" icon="database" href="/integrations/supabase">
    Full reference for Supabase in Newly
  </Card>

  <Card title="Adding Authentication" icon="user" href="/guides/adding-authentication">
    Email/password auth and protected routes
  </Card>

  <Card title="Connect a Database" icon="table" href="/guides/connecting-database">
    Store user-specific data
  </Card>

  <Card title="Preview vs Builds" icon="mobile" href="/guides/preview-vs-builds">
    Why native login needs a real build
  </Card>
</CardGroup>