If your TestFlight build came back with a Guideline 4.8 message about Login Services, the rejection is almost always about one missing option on your sign-in screen. You added Google or Facebook login, and Apple wants an equivalent that protects the user's name, email, and behavior the same way.
Short answer
Guideline 4.8 (Login Services) requires that if your app uses a third-party or social login to set up the user's primary account, you must also offer another login service that limits data collection to name and email, lets users hide their email, and does not collect in-app interactions for advertising without consent. The text was updated in January 2024 to remove the explicit name Sign in with Apple, but the three privacy filters still describe Sign in with Apple in practice. Five exceptions exist for enterprise, education, government identity, alternative marketplaces, and pure third-party clients.
What you should know
- The trigger is the primary account. Guideline 4.8 looks at the login that creates and authenticates the user's main identity in your app, not optional secondary connections.
- Three filters define an equivalent option. Name and email only, optional email privacy, and no behavioral tracking for advertising without consent.
- Sign in with Apple is the de facto answer. Apple removed the literal requirement in January 2024 but kept the filters that effectively describe Sign in with Apple.
- Five exceptions remove the duty. Enterprise, education, government identity, alternative marketplace, and pure third-party-service clients.
- Account deletion is a paired gate. Apps offering Sign in with Apple must also support in-app account deletion and revoke Apple tokens through the right endpoint.
- Design and styling still cause rejections. The Human Interface Guidelines define button copy, padding, contrast, and the rule against asking for a separate name after Sign in with Apple completes.
What exactly does Guideline 4.8 say in 2026?
According to Apple's App Review Guidelines section 4.8 (Login Services), an app that uses a third-party or social login service such as Facebook Login, Google Sign-In, Sign in with Twitter, Sign In with LinkedIn, Login with Amazon, or WeChat Login to set up or authenticate the user's primary account must also offer as an equivalent option another login service with three filters. The other service must (1) limit data collection to the user's name and email address, (2) allow users to keep their email address private as part of setting up their account, and (3) not collect interactions with the app for advertising purposes without consent.
The guideline text changed in January 2024. Before that, the rule named Sign in with Apple explicitly. After the update, 9to5Mac reported on January 27, 2024 that Apple now describes the option by feature rather than by name. The practical effect is small. Sign in with Apple is the only mainstream identity provider that satisfies all three filters out of the box.
The guideline also defines what a primary account is. It is the account the user establishes with your app to identify themselves, sign in, and reach your features. Optional connections to external services that are not the user's primary identity in your app do not trigger the rule.
Why did my build get rejected when I added Google or Facebook login?
The standard rejection cites Guideline 4.8 (Design: Login Services) and quotes a paragraph close to this: the app uses a third-party login service but does not appear to offer an equivalent option that meets the three filters. The pattern shows up in the Apple Developer Forums thread on Guideline 4.8 Design Login Services, where developers consistently report adding Google Sign-In without offering anything else, and getting a Resolution Center notice within hours of submission.
The reviewer is checking whether the user can complete sign-up using a path that meets all three filters. A guest mode without persistence does not count, because it is not a login service. A custom email and password screen counts as your company's own account system, which sits inside the first exception, but only when it is the exclusive sign-in path. Mixing your email and password screen with Google Sign-In does not satisfy the rule, because Google Sign-In is still present as a third-party login that does not meet the email privacy filter.
In practice, the resolution that consistently clears the rejection is adding Sign in with Apple alongside the other third-party providers, on every primary sign-up and sign-in surface in the app.
Which equivalent login service actually meets all three filters?
Few providers meet all three filters out of the box. The table below compares common options against the Guideline 4.8 text.
| Provider | Limits to name and email | Hidden email option | No ad tracking by default | Accepted by reviewers |
|---|---|---|---|---|
| Sign in with Apple | Yes | Yes (Hide My Email) | Yes | Yes |
| Google Sign-In | Yes with minimal scopes | No native relay | Mixed; ad signals on the Google account | No |
| Facebook Login | Optional, often more requested | No | Tracks for advertising by default | No |
| Sign in with X (Twitter) | Yes with minimal scopes | No | No native restriction | No |
| LinkedIn or Amazon login | Yes with minimal scopes | No | No native restriction | No |
| Email and password (your system) | Yes | Yes if you hash | Yes | Yes, only if exclusive |
The honest answer is that Sign in with Apple is the option that closes the rejection without an exception argument. Anything else asks the reviewer to accept a privacy claim that Apple has not validated, and reviewers rarely take that route.
When does Guideline 4.8 not apply (the five exceptions)?
The guideline lists five carveouts where another login service is not required.
The first exception covers apps that exclusively use the company's own account setup and sign-in systems. A pure email and password flow you operate yourself, with no third-party login at all, falls here. Adding Google Sign-In on top removes this exception.
The second exception covers alternative app marketplaces, or apps distributed from one, where the marketplace login handles account, download, and commerce features. This carveout grew out of the EU Digital Markets Act regime in 2024.
The third exception covers education, enterprise, or business apps where the user signs in with an existing education or enterprise account. A school app that requires a district single sign-on falls here. A general productivity app that offers Google Sign-In to consumers does not.
The fourth exception covers apps that use a government or industry-backed citizen identification system or electronic ID to authenticate users. National e-ID schemes and bank-grade identity providers in regulated markets fall here.
The fifth exception covers clients of a specific third-party service, where the user must sign in to their mail, social media, or other third-party account directly to access content. A dedicated Gmail client that uses Google Sign-In to reach the user's own Gmail mailbox falls here. A generic todo app that uses Google Sign-In does not.
How do I clear the 4.8 rejection and resubmit cleanly?
A working fix combines four things: a correct Sign in with Apple implementation, a button that respects the Human Interface Guidelines, an account deletion path that revokes Apple tokens, and a clean Resolution Center reply.
On iOS, the capability is enabled in Xcode under Signing and Capabilities, which provisions the entitlement. The framework is AuthenticationServices, and the relevant types are ASAuthorizationAppleIDProvider, ASAuthorizationAppleIDRequest, and ASAuthorizationController. Request scopes [.fullName, .email] only; that keeps you inside the Guideline 4.8 envelope. The identityToken returned to your app is a JWT signed by Apple. Your backend verifies it against Apple's public keys and binds the sub claim to a server-side account. The email returned can be a private relay address ending in @privaterelay.appleid.com, which forwards to the real address. Treat it as the user's email, and do not ask for a separate one.
The button must follow the Sign in with Apple Human Interface Guidelines for title (one of the approved variants such as "Sign in with Apple" or "Continue with Apple"), corner radius, padding, and the dark or light variant in context. Asking the user to retype their name after Sign in with Apple completes with .fullName granted is the most common style rejection on top of 4.8.
The account deletion path matters because Apple made in-app deletion a Guideline 5.1.1 (v) requirement for apps with account creation since June 2022. Your code must call the Apple revoke endpoint on the refresh token, so the Apple ID also drops the app link. A 4.8 fix without an account deletion path often comes back as a 5.1.1 (v) rejection on the next round.
Add Sign in with Apple to every primary sign-up and sign-in surface, including the first-run screen, the settings flow that lets users link a new method, and any "log in to access feature" interrupt. Reply in the App Store Connect Resolution Center with a short note naming the screens you changed, and (if helpful) attach a 30-second screen recording. For builders working with AI-coded or no-code stacks where the sign-in surface is generated, a pre-submission scan against OWASP MASVS authentication controls on the compiled IPA catches missing capabilities, broken button wiring, and credential handling defects before App Review sees them. PTKD.com (https://ptkd.com) is one of the platforms focused specifically on that kind of pre-submission read for iOS builds.
What to watch out for
- Guest mode is not a substitute. A path that does not create a persistent account is not a login service, and it does not close the Guideline 4.8 gap.
- Email and password alone works only if it is exclusive. Adding Google Sign-In on the same screen takes you out of the first exception and back into the rule.
- Hide My Email is not optional UX. The reviewer expects that the user can complete sign-up without revealing their real address.
- The myth that Microsoft, GitHub, or LinkedIn satisfies 4.8. None of those providers meet all three filters by default, and adding one without Sign in with Apple does not close the rejection.
- Do not collect a second name after Sign in with Apple completes. It is the most common design rejection stacked on top of a 4.8 issue.
- Account deletion is a paired gate. A 4.8 fix without an account deletion path often comes back as a Guideline 5.1.1 (v) rejection on the next round.
Key takeaways
- Guideline 4.8 is triggered by any third-party login that creates the user's primary account, and it asks for an equivalent option that limits data, hides email, and does not track for advertising.
- The January 2024 text update dropped the literal Sign in with Apple requirement, but the three filters still describe Sign in with Apple in practice.
- Five exceptions exist (own account system, alternative marketplace, education or enterprise, government identity, third-party service client). Use them only when the carveout genuinely applies; mixing them with Google Sign-In does not work.
- A clean iOS fix covers the AuthenticationServices capability, the button styled per the Human Interface Guidelines, identityToken validation against Apple's public keys, and an account deletion path that revokes Apple tokens.
- For teams shipping AI-coded or no-code apps where the sign-in surface is generated and the binary is hard to audit by eye, scanning the compiled IPA against OWASP MASVS using a platform such as PTKD.com (https://ptkd.com) catches missing capabilities, broken Sign in with Apple wiring, and account deletion path gaps before App Review does.
