Guideline 4.8 Login Services: Sign in with Apple required?

Guideline 4.8 applies as soon as your app uses Google, Facebook or another third-party login to create the primary account. It then requires another, equivalent login option that limits data to name and email, lets users hide their email, and doesn't track them for advertising without their consent. Since January 2024, that option doesn't have to be "Sign in with Apple", but it's the one Apple itself names in its rejection messages.

In my own apps, Solys and Nolera offer Apple, Google and email. This guide starts from Apple's current text, then shows how I add Sign in with Apple to an Expo app connected to Supabase, and what it changes for account deletion. For the big picture on rejection reasons, read why Apple rejects an app instead.

What does guideline 4.8 Login Services say?

4.8 sits in section 4, "Design", of the App Review Guidelines. It targets apps that use "a third-party or social login service" to set up or authenticate the primary account: Facebook Login, Google Sign-In, Log in with X, LinkedIn, Amazon or WeChat. These apps must also offer, "as an equivalent option", another login service that meets three conditions.

Apple's condition	In plain words
Limited data	Name and email, nothing more
Private email possible	The user can hide it
No ads without consent	No ad tracking without consent

The text also defines the primary account: the one a person creates in your app to identify themselves, sign in and access your features. Based on that definition, a Google button that only serves to import a file doesn't create a primary account. 4.8 targets the screen where people get into your app.

What changed in January 2024

Before 2024, the rule required "Sign in with Apple" for apps that used a third-party login for the primary account. On January 25, 2024, Apple relaxed this: you can offer Sign in with Apple, or an equivalent privacy-protecting service. Lots of pages still say otherwise. The Expo documentation still says an app with a third-party login must offer Apple.

In practice, the 4.8 rejection message posted on Apple's developer forums ends like this: "Note that Sign in with Apple meets the requirements specified in guideline 4.8". Apple names no other compliant service. So I don't play guessing games with the reviewer: I add Sign in with Apple.

The five exceptions in the text

Apple lists five cases where no other login is required:

1. Your app only uses your own account system, for example email and password or a code sent by email.
2. Your app is an alternative app marketplace, or is distributed by one, with a marketplace-specific login.
3. Your app is educational, enterprise or business, and requires an existing school or company account.
4. Your app uses a government- or industry-backed electronic ID system.
5. Your app is a client for a specific third-party service: the person signs in to their email or social network to access their own content.

Before you even look at these exceptions, ask yourself: does your app need an account at all? If it doesn't, guideline 5.1.1(v) asks you to keep it usable without signing in, as I explain in the guideline 5.1.1 guide.

Your sign-in screen	Does 4.8 apply?
No account	No
Email or code only	No
Google only	Yes
Google and email	Yes, most likely
Google and Apple	Yes, and compliant
Existing school account	No
Google for an import	No, no account

Adding "Sign in with Apple" to an Expo app

1. Install the module and declare the capability

npx expo install expo-apple-authentication

The Expo docs then tell you to enable the capability in the app config:

{
  "expo": {
    "ios": {
      "usesAppleSignIn": true,
      "infoPlist": { "CFBundleAllowMixedLocalizations": true }
    }
  }
}

The second line shows the button in the iPhone's language. With EAS Build, the capability is enabled on your app identifier at build time. It's a native setting: it ships with a new build, never with an over-the-air update.

A trap I found while rereading the starter code of my kits: this capability requires signing, even to run the app on the simulator. On a Mac without an "Apple Development" certificate, the local build failed with "No code signing certificates are available to use". The fix: only enable Sign in with Apple once the auth server is configured.

2. Show the official button, as visible as Google's

Apple's design guidelines are clear: the Apple button must not be smaller than the other sign-in buttons, and people shouldn't have to scroll to see it. Expo's component draws the official button, with an Apple-approved title.

import * as AppleAuthentication from "expo-apple-authentication";
import { useEffect, useState } from "react";

export function BoutonApple({ onPress }: { onPress: () => void }) {
  const [disponible, setDisponible] = useState(false);

  useEffect(() => {
    AppleAuthentication.isAvailableAsync().then(setDisponible);
  }, []);

  // Android and web: no Sign in with Apple, no button.
  if (!disponible) return null;

  return (
    <AppleAuthentication.AppleAuthenticationButton
      buttonType={AppleAuthentication.AppleAuthenticationButtonType.CONTINUE}
      buttonStyle={AppleAuthentication.AppleAuthenticationButtonStyle.BLACK}
      cornerRadius={12}
      style={{ width: "100%", height: 50 }}
      onPress={onPress}
    />
  );
}

Expo notes that the button won't appear without a width and height. Color and corner radius go through buttonStyle and cornerRadius, not through the style.

3. Open the session in Supabase

import * as AppleAuthentication from "expo-apple-authentication";
import { supabase } from "./supabase";

export async function connexionApple(): Promise<"ok" | "annule"> {
  try {
    const credential = await AppleAuthentication.signInAsync({
      requestedScopes: [
        AppleAuthentication.AppleAuthenticationScope.FULL_NAME,
        AppleAuthentication.AppleAuthenticationScope.EMAIL,
      ],
    });
    if (!credential.identityToken) throw new Error("Missing Apple token");
    const { error } = await supabase.auth.signInWithIdToken({
      provider: "apple",
      token: credential.identityToken,
    });
    if (error) throw error;
    // The first name only comes with the first authorization: save it right away.
    const prenom = credential.fullName?.givenName;
    if (prenom) await supabase.auth.updateUser({ data: { prenom } });
    return "ok";
  } catch (e) {
    if ((e as { code?: string }).code === "ERR_REQUEST_CANCELED")
      return "annule";
    throw e;
  }
}

Four details matter, taken from the Supabase documentation, Expo's docs and Apple's design guidelines:

• In Supabase, add your bundle identifier to the Client IDs of the Apple provider. A native-only app doesn't need a secret key to sign in. Add host.exp.Exponent if you test in Expo Go.
• The first name and email only arrive once. Apple doesn't send them again on later sign-ins: save them on the very first response.
• The email may be a relay address. Apple recommends not asking for a personal address afterward.
• A cancellation isn't an error. In Nolera, closing the Apple sheet doesn't trigger any red message: it's a deliberate action.

A real case from Solys, in August 2026: the Apple and Google buttons were in the app, but neither provider was enabled in Supabase. The code was fine, the fix happened on the server side, no new build needed. An Apple button that fails in front of the reviewer gets you a 2.1 rejection instead of a 4.8 one. Details are in the guideline 2.1 guide.

4. Test on a real iPhone

Expo warns that the simulator only allows limited testing, and that the credentials you get in Expo Go differ from those of the published app. Test sign-in, sign-out and then signing back in on a real iPhone, with a TestFlight build.

Sign in with Apple and account deletion

Guideline 5.1.1(v) requires that an account created in the app can be deleted from within the app. With Sign in with Apple, Apple's page on account deletion adds a step: use the Sign in with Apple REST API to revoke the person's tokens.

Revocation needs two things: a token for the person, which you get by validating an authorization code, and a secret signed with your Sign in with Apple private key. Even though native sign-in works without a secret key, revocation requires one, and it stays on your server. The why is in secret API key in an Expo app.

In Nolera, when you delete your account, the app asks you to sign in with Apple again to get a fresh authorization code. It sends it to a server function, which exchanges it with Apple and then revokes the token. If the person cancels, a clear message says so and nothing is deleted. The rest of the flow, including data, subscription and testing, is in iOS account deletion.

How to reply to Apple after a 4.8 rejection

Apple's message offers two ways out. Either you add an equivalent option. Or your app already has one: you reply in App Store Connect, say which one and why it meets the three conditions. Apple also suggests updating any screenshots that show the sign-in screen. The process to reply to App Review is the same as for other guidelines.

Here's a template in English to adapt (replace the build number):

Hello,

Thank you for your review.

Build X adds Sign in with Apple as an equivalent login option.
It appears on the same screen as Google Sign-In, with the same
size, and is visible without scrolling.

How to verify: launch the app, open the sign-in screen and
tap "Continue with Apple".

We also updated the screenshots that show the sign-in screen.

Best regards,

The 4.8 checklist before you submit

• You know whether your app needs an account. If not, it works without signing in.
• If Google, Facebook or X create the account, Sign in with Apple is on the same screen.
• The Apple button is the official one, as big as the others, visible without scrolling.
• The Apple provider is enabled on the server, with your bundle identifier.
• A cancellation takes you back to the sign-in screen, with no error message.
• The first name and email are saved on the first sign-in.
• Account deletion revokes the Apple token, from your server.
• Everything is tested on a real iPhone, with an Apple Account that has never signed in to the app.
• Your screenshots show the sign-in screen exactly as it is in the submitted build.

Fix your rejection before resubmitting

If your app just got a 4.8 rejection, the Apple Review Kit bundles everything I check before each submission, with two skills that review your project in Claude Code and draft your reply if Apple rejects it. If you want a human look, book an hour with me: we read the message together and look at your sign-in screen. The full process after a rejection is on the app rejected by Apple page.

If you're preparing your first release, take the free diagnostic: it tells you which step to tackle first and sends you my Apple anti-rejection checklist.

Nobody can guarantee Apple will accept your app. Adding Sign in with Apple in the right place at least takes this reason off the list.

Frequently asked questions

Is Sign in with Apple mandatory on iOS?

No, not in every case. It's only required if your app offers a third-party login, like Google or Facebook, to create the primary account. Since January 2024, another equivalent service can replace it, but Apple only names Sign in with Apple as compliant.

What does "Guideline 4.8 - Design - Login Services" mean?

It's the rejection title in Apple's message. It means your app offers a third-party login without an equivalent option that limits data to name and email, lets users hide their email, and isn't used for advertising without consent.

Is my email sign-up enough alongside Google?

That's not guaranteed. The text asks for a service that lets people keep their email private, while a standard form asks for it. Apple hasn't published a position on this case, and its rejection message only names Sign in with Apple. I wouldn't take that risk.

Do I need to offer Sign in with Apple on Android?

No. 4.8 is an App Store rule, and Expo's module only works on iOS. On Android, isAvailableAsync() returns false: the Apple button doesn't show, and Google can stay on its own.

Do I need a new build after a 4.8 rejection?

Yes, in most cases. Sign in with Apple requires a native capability, enabled at build time. An over-the-air update can't add it. The only exception: your app already had a compliant option, and you just need to explain it to Apple in your reply.