Do you actually have to offer Sign in with Apple?

Most developers carry around a one-line version of the rule: if you have Google sign-in on iOS, you must add Sign in with Apple. It’s close enough to keep you out of trouble, and it’s still wrong in both directions. The current guideline never names Sign in with Apple, some apps with Google sign-in don’t need it at all, and adding it commits you to more than a button. Here is what the rule says, who it skips, and the work that comes with saying yes.

What Guideline 4.8 actually says

The rule is App Review Guideline 4.8, Login Services. It applies to apps that use “a third-party or social login service (such as Facebook Login, Google Sign-In, Log in with X, Sign In with LinkedIn, Login with Amazon, or WeChat Login) to set up or authenticate the user’s primary account with the app.” Those apps must also offer, “as an equivalent option”, another login service that does three things:

It limits data collection to name and email. It lets people keep their email address private when they set up the account. It doesn’t collect their interactions with your app for advertising without consent.

That is a description, not a product name. Earlier versions of the guideline named Sign in with Apple outright; the current text describes features instead. In practice Sign in with Apple is the service almost everyone uses to meet it, because it ticks all three boxes and ships in the OS. But the obligation is to offer a private-by-default option, and that matters when you read the edge cases.

Note what doesn’t meet it. Google sign-in fails the second test, since it hands you the person’s real Gmail address. A plain email-and-password form is a hard argument to make too: the one thing it can’t let people keep private is their email address, because that’s what it asks for.

Two words that decide most cases: “primary account”

The rule only bites when the third-party login creates or authenticates the user’s primary account, which Apple defines as “the account they establish with your app for the purposes of identifying themselves, signing in, and accessing your features and associated services.”

So a notes app with its own accounts that asks for Google sign-in only to back files up to Drive isn’t using Google as a login service. Google is a connected integration there, not the identity. Same for an app that connects to a user’s GitHub to read their repositories while signing them in some other way. Once “Continue with Google” is the thing that makes an account exist, you’re inside 4.8.

The five apps that are exempt

Apple lists five cases where the extra login service isn’t required. Paraphrased:

Your own accounts only. The app “exclusively uses your company’s own account setup and sign-in systems.” The word doing the work is “exclusively”. Add a single social login next to your email form and the exemption is gone.

Alternative marketplaces. An alternative app marketplace, or an app distributed from one, using a marketplace-specific login for account, download and commerce features.

Education, enterprise and business apps that require signing in with an existing education or enterprise account. Think a school’s learning app that only accepts the district’s accounts.

Government or industry-backed ID. Apps that authenticate with a citizen identification system or electronic ID.

Clients for a specific third-party service. If the app exists to show someone their mail, social media or other account, and they have to sign in to that service directly to see their content, you don’t need to offer anything else. A third-party Mastodon client is the classic case: signing in with Apple would give it nothing to show.

If you’re not in one of those five and your sign-up screen has a social button, plan on Sign in with Apple.

“Equivalent” covers where the button goes

The guideline says “equivalent option”, and Apple’s Human Interface Guidelines spell out what that looks like: “Make a Sign in with Apple button no smaller than other sign-in buttons, and avoid making people scroll to see the button.” Burying it under “More options” while Google gets the full-width slot is the version that draws attention.

Use the system button rather than drawing your own. It comes in three appearances (white, white with an outline, black), translates its own title, takes a corner radius to match your UI, and has a VoiceOver label built in. Pick black on light backgrounds and white on dark ones; the outlined white is for white backgrounds where the plain white button would vanish.

What you’re signing up for

The button is an afternoon. These four things are what make Sign in with Apple users second-class citizens in apps that didn’t plan for them.

The name arrives once. Apple returns the user’s name on the first authorization and not on later sign-ins, a behavior auth providers such as Supabase document for exactly this reason. If your first sign-in handler fails before it saves the name, or you wire up the display name in a later release, those users show up as “Hi, there” forever unless they revoke and re-authorize. Save the name in the same step that creates the account, and treat it as optional from then on.

Relay addresses only accept mail you registered. People who choose Hide My Email give you a random relay address. Apple’s configuration docs say that to email them, “you must register your outbound email domains, subdomains, or email addresses as email sources for the Private Email Relay Service”, and those domains must pass SPF, DKIM, or both (Apple recommends both). Individual developer accounts can register up to 32 sources, organizations up to 100. The trap is the sender you forgot: your transactional email provider, the receipts service, the newsletter tool. Every unregistered sender is a set of password resets and receipts those users never get. The relay service does email your account holders and admins when it detects undelivered mail, so make sure someone reads that inbox.

Apple will tell your server when things change. You can register one server-to-server notification endpoint per app group, over TLS 1.2 or later. It receives signed events when a user turns relay forwarding off (email-disabled) or back on (email-enabled), stops using their Apple Account with your app (consent-revoked), or deletes their Apple Account entirely (account-deleted). If you skip this, you’ll keep sending to addresses that no longer forward and keep accounts for people who have left.

Deletion means revoking tokens. Apple requires in-app account deletion for any app that lets people create an account. For Sign in with Apple users, deleting the account also means revoking their tokens with a server-side call. Our account deletion post walks through that flow.

If you also ship on Android and the web

Guideline 4.8 is an App Store rule; Google Play has no equivalent requirement. But the moment an iPhone user creates an account with Apple, that is their identity on every platform your backend serves. If your Android app or website only offers Google and email, the person who signed up on iOS with a relay address can’t get in anywhere else.

Sign in with Apple works off Apple platforms through a web flow. You register a Services ID in Certificates, Identifiers & Profiles, verify every domain and subdomain that uses it, and list absolute return URLs (up to 10 for individuals, 100 for organizations). Most auth providers, Firebase Auth included, wrap that flow, but the Services ID setup is still yours to do. Plan it before launch, not after the first support email from someone stuck on a Pixel.

Sign-in is one of the screens App Review looks at first. When the binary is ready, ShotCanvas handles the other half of the submission: the screenshots, metadata and upload.