If your Flutter app offers any third-party login on iOS — Google, Facebook, anything — Apple's App Review guideline 4.8 forces you to also offer Sign in with Apple.
Skipping it is a guaranteed App Store rejection.

That part is non-negotiable.
The painful part is the setup: Apple Developer Console, Services IDs, .p8 keys, capabilities, entitlements, deep links — and most of it is only documented across three or four different Apple and Supabase pages that don't quite agree with each other.

This is the guide I wish I'd had the first time. End-to-end Apple Sign-In with Flutter and Supabase, every step in order, with the gotchas called out where they actually bite.

What you'll have at the end

• Apple Sign-In working on iOS, macOS, and Android.
• A clean Flutter helper that wraps the native flow and returns a Supabase AuthResponse.
• A clear understanding of when you need a Services ID (and when you don't).
• The right handling for the "Apple only sends name and email once" gotcha.

Step 1 — Apple Developer Console

Open the Apple Developer portal and head to Certificates, Identifiers & Profiles → Identifiers.

Enable Sign In with Apple on your App ID

1. Select your existing App ID (the one matching your Flutter app's bundle identifier).
2. Scroll down, check Sign In with Apple, and save.

That's the minimum required for the native iOS / macOS flow. If you only target those two platforms, you can skip directly to Supabase setup.

Create a Services ID (web + Android only)

If you also need to support Android or web, you have to add a Services ID. This is what powers the OAuth redirect flow Supabase uses on platforms where Apple has no native SDK.

1. In Identifiers, click + and choose Services IDs.
2. Set an identifier — convention is to suffix .service to your bundle ID (e.g. com.example.app.service).
3. Enable Sign In with Apple → Configure.
4. Add your Supabase domain to the allowed domains: <PROJECT_REF>.supabase.co.
5. Add the return URL: https://<PROJECT_REF>.supabase.co/auth/v1/callback.

Create a Sign In with Apple key

Still in the Apple Developer portal, go to Keys → + and check Sign In with Apple. Download the resulting .p8 file — this is the only time it's downloadable, so back it up immediately.

You'll need three things to generate the Secret Key JWT in Step 2:

• Key ID (visible after creating the key)
• Team ID (top right of the Apple Developer portal)
• The .p8 file's contents (open it in a text editor)

Step 2 — Supabase Dashboard

Generating the Secret Key JWT

The current Supabase dashboard expects the JWT itself — you sign it locally, then paste the result. You'll need the .p8 file, your Team ID, your Key ID, and your Services ID.

Sign an ES256 JWT with this payload (a small Node, Python, or Ruby script will do — search "apple sign in client_secret generator" for one-shot scripts):

{
  "iss": "<TEAM_ID>",
  "iat": <now>,
  "exp": <now + 15777000>,
  "aud": "https://appleid.apple.com",
  "sub": "<SERVICES_ID>"
}

Set the JWT header kid to your Key ID and alg to ES256. Paste the resulting token into the Secret Key field.

Apple JWTs expire after 6 months. Set a calendar reminder, because there's no warning when the token rolls over — your web and Android sign-ins will silently start failing. The native iOS/macOS flow is unaffected since it doesn't use the JWT.

iOS-only apps: skip half of this. The native flow sends an idToken straight to Supabase, which validates it against Apple's public keys. You don't need a Services ID, a .p8, or a Secret Key — just enable Apple as a provider and add your bundle ID to Client IDs.

Or simply use Supabase JWT Generator to generate the JWT for you. Just remember to set a reminder to regenerate it every 6 months.

Setup the provider in Supabase

In your Supabase project, go to Authentication → Providers → Apple and toggle Enable Sign in with Apple.

The dashboard exposes four fields plus a callback URL:

• Client IDs — comma-separated list of allowed bundle IDs (for the native flow) and Services IDs (for the web flow). For an iOS-only app, this is just your bundle ID (e.g. com.example.app). If you target web or Android too, append your Services ID: com.example.app, com.example.app.service.
• Secret Key (for OAuth) — the JWT you generated above. Required only for the web/Android redirect flow, ignored for native iOS/macOS.
• Allow users without an email — toggle this on if you want to accept users who hide their address via Apple's email relay. Otherwise sign-in silently fails for them and you'll spend an afternoon wondering why.
• Callback URL (for OAuth) — auto-generated by Supabase as https://<PROJECT_REF>.supabase.co/auth/v1/callback. This is the URL you registered in Apple Developer at Step 1's Services ID. If you skipped that step, copy the URL from here and add it to your Services ID configuration now.

Save.

Step 3 — iOS configuration

In Xcode, open the Runner target → Signing & Capabilities → + Capability → Sign In with Apple.

That's the entire iOS setup. No Info.plist changes, no manual entitlements editing — Xcode handles the entitlement file automatically when you add the capability.

Step 4 — macOS configuration

Same path: target Runner → Signing & Capabilities → + Capability → Sign In with Apple.

Then double-check the entitlements file (macos/Runner/DebugProfile.entitlements and Release.entitlements) contains:

<key>com.apple.developer.applesignin</key>
<array>
  <string>Default</string>
</array>

While you're there, make sure Outgoing Connections (Client) is enabled — you'll need it to talk to Supabase.

Step 5 — Android configuration

Apple has no native SDK on Android, so you fall back to the OAuth redirect flow handled by Supabase:

await Supabase.instance.client.auth.signInWithOAuth(
  OAuthProvider.apple,
  redirectTo: 'your-scheme://callback',
);

For the redirect to come back into your app, register the deep link scheme in android/app/src/main/AndroidManifest.xml:

<intent-filter>
    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />
    <data android:scheme="your-scheme" android:host="callback" />
</intent-filter>

The user gets a webview-based login instead of the system sheet. Not as polished as iOS, but it's the only route Apple gives us on Android.

💡 Note: I personnaly don't recommend offering Apple Sign-In on Android at all, since the user experience is so much worse than the native iOS sheet.
If you do want to offer it, make sure to also offer Google Sign-In as an alternative — Android users are more familiar with Google than Apple, and may not even know they have an Apple ID to sign in with.

Step 6 — Flutter dependencies

Three packages do all the work:

dependencies:
  sign_in_with_apple: ^6.x.x
  supabase_flutter: ^2.x.x

sign_in_with_apple triggers the native Apple sheet on iOS/macOS. supabase_flutter handles the token exchange. crypto lets us hash the nonce — which we get to next.

Step 7 — The Flutter code (native iOS / macOS flow)

This is the function I drop into every project. It generates a nonce, triggers the Apple credential request, and forwards the resulting idToken to Supabase:

Future<AuthResponse> signInWithApple() async {
  // 1. Generate a nonce
  final rawNonce = client.auth.generateRawNonce();
  final hashedNonce = sha256.convert(utf8.encode(rawNonce)).toString();

  // 2. Trigger the native Apple sheet
  final credential = await SignInWithApple.getAppleIDCredential(
    scopes: [
      AppleIDAuthorizationScopes.email,
      AppleIDAuthorizationScopes.fullName,
    ],
    nonce: hashedNonce,
  );

  final idToken = credential.identityToken;
  if (idToken == null) {
    throw Exception('Apple Sign-In returned no idToken');
  }

  // 3. Exchange the idToken with Supabase
  return Supabase.instance.client.auth.signInWithIdToken(
    provider: OAuthProvider.apple,
    idToken: idToken,
    nonce: rawNonce,
  );
}

Three things happening here, in order:

1. We generate a random rawNonce and pass its SHA-256 hash to Apple.
2. Apple bakes that hash into the signed idToken it returns.
3. We send the raw nonce (unhashed) to Supabase, which re-hashes it and confirms it matches what Apple signed.

That round-trip is what protects you from replay attacks.

Step 8 - link anonymous accounts (optional)

If you support anonymous login, you can link the Apple credential to the existing anonymous user instead of creating a new account:

@override
Future<void> signupFromAnonymousWithApple() async {
  final credential = await SignInWithApple.getAppleIDCredential(
    scopes: [ AppleIDAuthorizationScopes.email],
  );
  final response = await client.auth.linkIdentityWithIdToken(
    provider: OAuthProvider.apple,
    idToken: credential.identityToken!,
  );
}

1 - The user triggers Apple Sign-In from an anonymous session.
2 - We get the Apple credential as before.
3 - Instead of signInWithIdToken, we call linkIdentityWithIdToken to link the Apple provider to the existing anonymous user.

Gotchas that will bite you

Apple sends name and email only on the first sign-in

This is the bug every team hits in production. The first time a user authorizes your app, the AppleIDCredential includes givenName, familyName, and email. On every subsequent sign-in for the same Apple ID, those fields are null.

The fix: persist name and email in your own database the very first time you receive them. After that, read from your database, not from Apple's payload.

final user = response.user;
if (credential.givenName != null) {
  // First sign-in — save the name to the profile
  await Supabase.instance.client.from('profiles').upsert({
    'id': user!.id,
    'first_name': credential.givenName,
    'last_name': credential.familyName,
    'email': credential.email,
  });
}

The nonce is mandatory, not optional

Some tutorials skip the nonce. Don't. Without it, Supabase cannot verify the idToken was issued for your specific request, and signInWithIdToken will reject it. The crypto package adds 12 KB to your app — that's the cheapest auth-security trade you'll ever make.

Services ID and .p8 aren't needed for native iOS

Worth repeating because it confuses people: if your app is iOS-only, you can ignore the Services ID and key entirely. The native flow sends the idToken straight to Supabase, which validates it against Apple's public keys. The .p8 is only used by the OAuth redirect flow on Android and web.

authorizationCode vs idToken

AppleIDCredential exposes both identityToken and authorizationCode. The authorizationCode is meant for server-side exchange (when you have your own backend that needs to talk to Apple). For Supabase, you want identityToken — signInWithIdToken does the rest.

Wrap-up

Apple Sign-In setup is one of the most thankless tasks in mobile development — the configuration is split across three platforms, the documentation is fragmented, and Apple actively makes some of it harder than it needs to be (looking at you, name-and-email-only-once).

Once it's wired correctly, though, it just works. The native sheet is fast, the user trusts it, and Apple reviewers stop rejecting your build.

If you want this — plus Google, Facebook, phone auth, anonymous login, and the whole reset-password / delete-account / account-management surface — already done and integrated with Supabase, ApparenceKit's social login templates ship with all of it. Apple Sign-In is one command in our authentication template — same code as above, but pre-wired into a clean Riverpod-based auth flow that follows our 3-layer architecture.

You can also check the Supabase Flutter starter for the broader template release if you're starting a new project from scratch.