A Guideline 4.8 rejection sounds like Apple is forcing you to add Sign in with Apple, and that is not quite what the rule says. If your app offers Google or Facebook login and App Review flagged 4.8, the fix is usually one screen change, and you have more than one compliant way to make it. Here is what the rule actually requires and the fastest route through it.
Short answer
Guideline 4.8 (Login Services) applies when your app uses a third-party or social login, such as Google Sign-In or Facebook Login, to set up or authenticate the user's primary account. Per Apple's App Store Review Guidelines, you must also offer an equivalent login that limits collected data to name and email, lets the user keep the email private, and does not track app activity for advertising without consent. Sign in with Apple meets all three, but it is not the only option.
What you should know
- The trigger is the primary account: 4.8 applies when a social login sets up or authenticates the main account, not when it is a minor convenience.
- Three privacy criteria define an equivalent login: name and email only, an optional private email, and no advertising tracking without consent.
- Sign in with Apple is sufficient, not mandatory: any provider meeting the three criteria satisfies the rule.
- Several app types are exempt: own-account-only apps, enterprise or education sign-in, government ID, and single-service clients.
- The fix is a binary change: adding a login option changes the build, so it requires a new submission, not a metadata reply.
Why did App Review flag your app under Guideline 4.8?
Because your sign-in screen offers a third-party social login as a way to create or access the primary account, with no equivalent privacy-focused option beside it. App Review checks the account-creation flow, sees Google or Facebook as the route to the main account, and applies 4.8. The guideline names the common services explicitly: Facebook Login, Google Sign-In, Sign in with Twitter, Sign In with LinkedIn, Login with Amazon, and WeChat Login. The practical signal is that the rejection cites 4.8 and points at your login screen, not at a binary error. If the social login is only used for a secondary feature and not to set up the primary account, the rule does not apply, though you may need to make that clear in the review notes.
What counts as an equivalent login service?
Any login that meets three privacy conditions. The equivalent option has to limit data collection to the user's name and email address, allow the user to keep that email address private during setup, and avoid collecting in-app interactions for advertising without consent. Sign in with Apple is built to satisfy all three, which is why it is the default choice, but a custom email login that meets the criteria, or another provider that does, is equally acceptable. The requirement is the privacy floor, not the brand of the button.
When are you exempt from offering another login?
Several app categories do not need a second login at all. Apple lists specific exemptions in Guideline 4.8, and if your app fits one, you can reply to the reviewer citing it rather than changing the screen. The table summarizes them.
| Your app | Second login required? |
|---|---|
| Uses only your own company's account and sign-in system | No |
| Is an alternative app marketplace, or distributed from one | No |
| Is an education, enterprise, or business app using an existing org account | No |
| Uses a government or industry-backed citizen ID or electronic ID | No |
| Is a client for one third-party service, where users sign in to that account directly | No |
| Offers Google, Facebook, or similar social login for the primary account | Yes, add an equivalent option |
If you qualify for an exemption, say so in the resolution reply with a short explanation, because reviewers apply these exceptions when the use of the account is clear.
How do you fix a 4.8 rejection, step by step?
The fix is to add a compliant login next to your social option, then resubmit. The order that works:
- Confirm the trigger: check that a social login creates or authenticates the primary account. If it does not, reply to the reviewer explaining the flow instead of changing it.
- Choose the equivalent login: Sign in with Apple is the fastest compliant choice for most apps, and a custom email login that meets the three criteria also works.
- Implement it: add the capability and the button to the same sign-in screen, with placement consistent with Apple's Human Interface Guidelines so the option is not hidden below the social buttons.
- Rebuild and resubmit: the change lives in the binary, so upload a new build, which returns the app to Waiting for Review for a full review.
- Note the change: in the resolution reply, point to the new login option so the reviewer can find it quickly.
For an Expo or React Native app, the Sign in with Apple capability is added through the project's entitlements and a community module. For FlutterFlow, it is enabled in the authentication settings and surfaced as a button in the sign-in flow. In every stack the requirement is the same: a compliant option visible at account creation.
What to watch out for
Two misreadings cause repeat rejections. The first is the assumption that 4.8 demands Sign in with Apple specifically; it does not, and a compliant alternative is fine, so do not rebuild around the wrong constraint. The second is hiding the equivalent option, for example placing it below the fold or styling it to look secondary, which can draw the same rejection again because the option is not genuinely equivalent. Guideline 4.8 is a design and account rule, so a binary scan does not detect it; the value of a pre-submission scan such as PTKD.com (https://ptkd.com) sits on the other side of the submission, on the compiled APK, AAB, or IPA, where a leftover key or permission is the kind of issue that forces its own new build. Fix the login flow for 4.8, and use the scan to avoid stacking a separate binary rejection on top of it.
What to take away
- Guideline 4.8 triggers when a social login like Google or Facebook sets up the primary account without an equivalent privacy-focused option beside it.
- The equivalent login must limit data to name and email, allow a private email, and avoid advertising tracking without consent; Sign in with Apple meets all three but is not mandatory.
- Check the exemptions first, because own-account, enterprise, education, government ID, and single-service client apps do not need a second login.
- The fix changes the sign-in screen, so it rides a new build; keep the binary clean with a pre-submission scan such as PTKD.com so one resubmission clears review.
