Sign in with Apple is only required when you offer another social login, and the name arrives exactly once.

When does Apple actually require Sign in with Apple?

The rule is narrower than its reputation. Guideline 4.8, Login Services, applies to apps that use a third-party or social login service to set up or authenticate the user's primary account. Apple gives examples: Facebook Login, Google Sign-In, Log in with X, Sign In with LinkedIn, Login with Amazon, WeChat Login. Those apps must also offer, as an equivalent option, another login service with three features. It limits data collection to the user's name and email address. It lets users keep their email address private as part of setting up their account. And it does not collect interactions with your app for advertising purposes without consent.

Notice what the guideline does not say. It never names Sign in with Apple. In principle any service meeting those three conditions qualifies. In practice Apple's own service is the one that meets them out of the box, which is why the requirement is known by its name rather than its wording. The phrase doing the work is primary account, which Apple defines as the account a person establishes with your app to identify themselves, sign in, and reach your features and associated services. A social share button is not a primary account. A Google button on your sign-up screen is.

Apple then lists five cases where another login service is not required. An app that exclusively uses your company's own account setup and sign-in systems. An alternative app marketplace, or an app distributed from one, using a marketplace-specific login. An education, enterprise or business app that requires the user to sign in with an existing education or enterprise account. An app using a government or industry-backed citizen identification system or electronic ID. And a client for a specific third-party service, where users must sign in to their mail, social media or other third-party account directly to reach their content. If your app only has your own user login, the first exception is yours.

This matters at submission, not at build time, which is why it surprises people. An app ships with one Google button because it was the quickest thing to wire up, and the rejection arrives after the build is done. Adding the option later is a day of work and another review cycle. Adding it the same afternoon as the Google button is an hour.

Apple, App Review Guidelines, guideline 4.8 Login Services, read 10 October 2026

What do you set up before the button works?

Inside an iOS app, the surface is small. You enable the Sign in with Apple capability for the app, either in Xcode or by editing the App ID configuration in Certificates, Identifiers and Profiles. You then choose one of two things: enable the App ID as a primary App ID, or group it with an existing primary App ID. Pick primary for a new app or an app you are enabling for the first time. Pick grouping when the identifier belongs to a related app, such as the iOS version of a Mac app. Grouping is not cosmetic. Apple states that it means users need to provide consent to share their information only once for each group of apps and websites.

A website or a non-Apple platform needs more. You register a Services ID for each web service, and that Services ID becomes the client identifier you authenticate with. You must already have an app in the App Store that uses Sign in with Apple before the web service can be enabled. You register and verify every top-level domain and subdomain involved, and the limits run per Services ID: organizations can register up to 100 website URLs, individuals up to 10. Return URLs have to be absolute, with a scheme, a host and a path. The redirect URI must use HTTPS, include a domain name, and cannot be an IP address or localhost, or contain a fragment identifier. You also create a private key to sign the tokens you send to Apple, and each primary app can hold a maximum of two.

Two details in the request itself cause most of the early confusion. The scope parameter accepts name and email, and you can ask for one, both or neither, space separated and percent encoded. If you request any scope at all, the response mode must be form_post, because the name cannot travel in a query string. The authorization code that comes back is single use and valid for five minutes, so it is exchanged on your server, not stored on the device for later. If this is the first login you are building, read the wider app authentication picture before you pick a provider.

One constraint is worth saying out loud because it shapes testing. Sign in with Apple requires two-factor authentication on the Apple Account. A native app only lets the signed-in iCloud user sign in, while web-based flows accept any Apple Account. On a simulator or a shared device that means you test with whoever is signed in at the system level, and an account without two-factor authentication cannot be used at all.

What does a hidden email address do to your backend?

During the sign-in sheet a person can edit their first and last name, choose a different contact address, or hide their address from your app. If they hide it, Apple generates a proxy address and forwards mail from it to their real inbox. The address you receive is real and deliverable. It is simply not the address they use anywhere else, so you cannot match it against an existing record, and you cannot treat it as a stable identity. That is the whole point of the feature from the user's side.

The domain changed recently, and this one breaks working code. Apple announced on 24 August 2026 that new Sign in with Apple addresses, previously issued on privaterelay.appleid.com, will be issued on private.icloud.com, with existing addresses on the old domain continuing to work and forward without interruption. Hide My Email addresses from iCloud+ stay on icloud.com. Apple's instruction is direct: account systems, email validation logic and allowlists should accept the new domain in addition to the old one. Any regular expression or suppression list that enumerates relay domains by hand needs the new entry, or valid sign-ups start failing validation.

Sending mail to a relay address is its own setup step, and it is easy to miss until a password reset bounces. You register your outbound email domains, subdomains or addresses as email sources for the private email relay service, under Services in Certificates, Identifiers and Profiles, through the configuration for Sign in with Apple for Email Communication. Email sources attach to your Developer Team ID: organizations can register up to 100, individuals up to 32, as Apple's account help described them on 10 October 2026. Every registered domain needs SPF, DKIM, or both, and Apple recommends both. The envelope sender domain has to be registered and match, and the DKIM signing domain has to match the address in the From header. When the relay detects undelivered mail from your account, it emails your team's account holders and admins.

Forwarding is also not permanent, which is the argument for server-to-server notifications. Register an endpoint on TLS 1.2 or later and Apple posts a signed payload when a user disables email forwarding, enables it again, revokes consent for your app, or asks Apple to delete their Apple Account. A permanent deletion invalidates all user tokens and disables email forwarding for every associated app, so an app that stores only the relay address has no way to reach that person and no way to know why. Key the account record on the user identifier instead, and let the email address be a changeable attribute.

Apple, Authenticating users with Sign in with Apple, read 10 October 2026

Why does the name only arrive on the first sign-in?

This is the single most common bug in a Sign in with Apple integration, and it is documented behaviour rather than a fault. Apple only returns the user object, the one holding the first name, last name and email, the first time a user authorizes your app. Subsequent authorization requests do not contain that object. The email address is still provided in the identity token on every response, and Apple is explicit that it does not include other information about the user, such as their name, on those later responses. So the second sign-in gives you an identifier and an email, and nothing to greet them with.

The name also travels differently from everything else. Apple does not receive the full name a person shares in the system sheet. The raw data is passed directly to your app and is not included in the identity token, which is why you cannot recover it later by decoding a token you already hold. Apple's own advice is to relay the credentials and user information to your servers, and to store what you receive locally straight away so your app still has it after a process or network failure. Because the values are user-submitted, validate and sanitise the first and last name before writing them anywhere, to avoid a cross-site scripting hole in your own admin screens.

Two behaviours make this look like an intermittent bug when it is not. First, app grouping: a person consents once per group of apps and websites, so an Android or web sign-in that follows an iOS one gets a plain confirmation and no name. Second, your own test account. It authorized the app on your first run, so every run after that is correctly nameless. Apple collects the information again only if the user stops using Sign in with Apple for your app and later reconnects, so revoking your app from your Apple Account settings is how you replay a genuine first sign-in. Real user status behaves the same way: the identification servers return it when someone uses your app and Sign in with Apple for the first time, and subsequent attempts do not return it.

The fix is dull and it works. Treat the first authorization as the only chance to learn who this is, write the name and email to your own store inside that same request, and build every screen after it from your record rather than from Apple's response. Then decide what happens when the name is genuinely absent, because a person who declined the name scope never had one. While you are in there, the same habit covers most of app security basics: hold the minimum, hold it once, and verify tokens on a server.

Apple, Authenticating users with Sign in with Apple, read 10 October 2026