Guideline 4.8: Login Services

A Guideline 4.8 rejection means your app offers a third-party or social login for the user's primary account, and does not also offer a login option that meets Apple's privacy conditions. In practice that means adding Sign in with Apple, because it is the option that obviously qualifies.

If your app has its own email and password signup and no social buttons, 4.8 does not apply to you, and a rejection citing it is worth questioning.

How it is usually worded

The header arrives as Guideline 4.8 - Design - Login Services, and the body is normally close to:

• "Your app uses a third-party login service, but does not offer an equivalent login option with the privacy features described in guideline 4.8."

What it actually means

The guideline used to be titled "Sign in with Apple" and required exactly that. It now describes the properties an alternative must have, rather than naming Apple's service. In substance:

• the service limits data collection to the user's name and email address
• the user can choose to keep their email address private as part of setting up the account
• the service does not collect interactions with your app for advertising purposes without consent

The requirement is conditional twice over: it applies only when a third-party or social login sets up or authenticates the user's primary account, and any option with those privacy properties satisfies it, not only Apple's.

The reason developers still just add Sign in with Apple is that arguing a competing service meets all three conditions is slower than shipping the button.

Why it triggers

• Google, Facebook, X, LinkedIn or Amazon sign-in as the only options. The classic case. One tap to create an account, no Apple option, rejection.
• Implemented but broken. The button exists and the entitlement is missing, the nonce check fails, or your verification email bounces off the private relay address, so the account never completes.
• A "primary account" you did not think of as one. If the social button creates a persistent account with saved state, it is a primary account, whatever you call it internally. Firebase Anonymous upgraded with a Google link counts.

What exempts you

These are the cases where 4.8 does not bite:

• Your app uses only your own account system with no third-party login option at all.
• Your app is an education, enterprise or business app that requires the user to sign in with an existing account issued by that school or organisation.
• Your app uses a government or industry-backed citizen identification system, or an electronic ID, to authenticate users.
• Your app is a specific third-party service's own client, and the user signs in to that service's account to use it. A mail client for one provider, or a client for one social network, is the shape here.

There is no exemption for "we do not want to", and none for "our users all use Google".

How to fix it, in order

1. Decide honestly whether you are exempt. If you are, the fix is a reply rather than code. See the template below.
2. Add the Sign in with Apple capability. In Xcode, Signing and Capabilities, add Sign In with Apple; then enable it for the App ID in the Developer portal so the provisioning profile carries the entitlement. A missing entitlement is the most common reason the button fails at runtime rather than at build.
3. Place it with the other buttons. Same screen, same prominence, on both signup and sign-in. Follow Apple's Human Interface Guidelines for the button itself rather than drawing your own.
4. Handle the private relay address properly. Treat the relay address as the account email. Register your outbound domain and sender for private email relay in the Developer portal, or your verification and receipt emails will silently fail.
5. Handle the name being sent once. Apple returns the full name only on the first authorisation. If you drop it, you cannot ask again through the API. Persist it on the first callback.
6. Test the revoke path. A user can revoke access in Settings; handle the dead credential as a sign-out, not a crash.
7. Do not demand data Apple's flow does not provide. Requiring a phone number before the account can exist undermines the option, and reviewers notice.

What to send back

If you added the button:

Thank you for the review. Sign in with Apple is now offered alongside Google and Facebook sign-in, on both the signup and the sign-in screens, with equal prominence and using the standard Apple button. The entitlement is enabled on the App ID and we have registered our sending domain for private email relay, so verification email reaches relay addresses. We tested account creation, sign-out, sign-in and credential revocation on the device and OS version named in the rejection.

If you believe you are exempt, say which exemption and why, once:

Thank you for the review. We believe guideline 4.8 does not apply to this app. The app is a client for [service], and the only sign-in it offers is the user's existing [service] account, which is required to access their own data. There is no separate primary account created in our app, and no social login is used to set one up. If you would prefer us to add Sign in with Apple regardless, please confirm and we will do so.

Keep that reply factual. The exemptions are real, and reviewers do accept them, but only when the app plainly matches one.

When it is really a different guideline

• Account creation that cannot be undone in the app is 5.1.1(v), account deletion.
• Requiring a login to see content that does not need an account is judged under 5.1.1, data collection and storage.

AppSubmit flags a missing Sign in with Apple entitlement when the build declares social login SDKs. That is a static check, not a guarantee; reading your own signup screen honestly is the better test.

Source: Apple, App Store Review Guidelines, 4.8 (https://developer.apple.com/app-store/review/guidelines/#login-services)

Related: apple-guideline-5-1-1-v-account-deletion, apple-guideline-4-0-design