Guideline 4.8: when social login requires Sign in with Apple
An app that offers third-party sign-in generally has to offer an equivalent option that does not collect more than name and email and lets the user keep both private. Sign in with Apple satisfies it; so do some other options that meet the same conditions.
Why it matters
The guideline is about the user having a choice that does not hand their identity to a third party, not specifically about Apple’s product. The requirement describes the properties a qualifying option must have, and Sign in with Apple is the one that obviously has them.
It binds apps that use a third-party login service exclusively. An app that offers its own email-and-password account alongside Google may already satisfy it, depending on what the app collects.
The entitlement being present in the project is evidence the feature exists, but not that it is offered in the sign-in interface, which is what a reviewer sees. This is graded as a risk rather than a blocker for that reason.
How to fix it
- Add Sign in with Apple as a capability and offer it in the same place as the other options, with comparable prominence.
- If you believe an existing option already qualifies, check it against the guideline’s conditions rather than against the general idea of it.
- Confirm the capability is enabled for your App ID and included in the distribution profile.
The guidelines behind it
Read from Apple’s App Review Guidelines as last updated October 16, 2026.
What ReviewAhead checks
Sign in with Apple. Apps offering third-party sign-in usually must also offer Sign in with Apple.
- Whether third-party authentication is present in the project.
- Whether the Sign in with Apple entitlement is present.
- Reports the combination rather than asserting a verdict, because whether an alternative qualifies depends on what your app collects.
Apple’s own documentation for this requirement: developer.apple.com. Where this page and Apple disagree, Apple is right and this page is a bug.