The Short Answer
Guideline 4.8 is Apple's Login Services rule. It says that if your app lets a user set up or authenticate their primary account through a third-party or social login service, such as Google Sign-In, Facebook Login, or Sign In with LinkedIn, you must also offer Sign in with Apple as an equivalent option, placed with the same prominence. App Review cites 4.8 when it finds a social login button on your sign-in screen with no Apple option sitting next to it. The fix is not to remove the social login, it is to add Sign in with Apple alongside it and make sure the data you ask for and the way you present it actually qualify as equivalent.
What Counts as an Equivalent Option
Apple is specific about what makes Sign in with Apple count as equivalent rather than just present. Three things matter most in practice.
- Equal prominence. Sign in with Apple needs to sit at the same visual weight as the other login buttons, not buried below a scroll or added as a smaller afterthought link.
- Limited data collection. You can request the user's name and email through Sign in with Apple, but nothing beyond that as part of the login step itself.
- Private relay support. Apple lets a user share a randomly generated relay address instead of their real email. Your backend has to accept and email that relay address like any other, because rejecting it defeats the point of offering privacy in the first place.
A Sign in with Apple button that technically exists but asks for more data than your Google button, or that is visually demoted, is the kind of implementation that still gets rejected under 4.8 even though the button is on the screen.
The Equivalent Option Test
App Store Launch Club members run three questions before submitting to decide if 4.8 applies at all, since it is easy to either assume you need it when you do not or miss it when you do.
- Does your app let a user set up or sign into their primary account using a third-party or social login, such as Google, Facebook, or X, or a login system that collects the user's name and email through an outside provider?
- Is that account a general consumer account, not one scoped to a single company's or school's own employees or students signing in with credentials that company or school already issued?
- Is your app a general-purpose app rather than a client built for one specific outside service where users are required to sign in directly to their existing account with that service?
A yes to all three means you need Sign in with Apple as an equivalent option. A no to any of them usually means you fall under one of Apple's own exemptions, covered next.
When 4.8 Does Not Apply
Common exemptions from the Sign in with Apple requirement
| Situation | Why it is exempt |
|---|---|
| Your own email-and-password system, no social login offered | 4.8 is triggered by offering a third-party login, not by having accounts at all |
| Enterprise or education app requiring an existing institutional account | The account is scoped to a specific employer or school, not a general consumer sign-up |
| App is a client for one specific outside service | Users sign in to an account they already hold with that exact service, not a general social login |
| Government or industry-backed identification system | Apple treats regulated identity systems separately from consumer social login |
Adding Sign in with Apple to an Expo App
In an Expo-managed app, Sign in with Apple is a native capability, not something you can fake with a web redirect. It needs three pieces working together: the capability enabled on your App ID in your Apple Developer account, the entitlement present in your app's build, and the client library that actually renders the button and returns the credential.
- Enable the Sign In with Apple capability on your App ID in your Apple Developer account before you build. Without it, the entitlement in your build has nothing to attach to and the flow fails silently on device.
- Install expo-apple-authentication and add it as a config plugin in your app config. EAS Build reads that plugin and writes the entitlement into your build automatically, so you are not hand-editing an Xcode project.
- Request only name and email as the scopes, matching what your other social logins collect. This is also what keeps you inside Apple's data-limiting requirement.
- Handle the case where the user chooses to hide their email. Apple's private relay address needs to work through your existing email pipeline exactly like a real address, including any transactional emails you send.
- Build and test on a real device signed into a real Apple ID, not the simulator alone. Sign in with Apple behaves differently the first time a user grants it versus every time after, and that difference is worth seeing before you submit.
Sign in with Apple is an iOS requirement only. Android has no equivalent rule from Google, so if you ship the same app to both stores through Expo, you can keep your existing Google and Facebook buttons on Android untouched and add Apple's button on the iOS build alone.
The Requirement That Shows Up Right Behind It: Account Deletion
Apps that let a user create an account are also required to offer account deletion reachable from inside the app, not just a support email address. This is a separate rule from 4.8, but reviewers commonly check both in the same pass, so an app that adds Sign in with Apple to clear a 4.8 rejection and still lacks in-app account deletion is a strong candidate for a second rejection right behind it. The full setup for account handling, including where this fits, is covered in [how to add authentication to your Expo app](/blog/how-to-add-authentication-to-your-expo-app).
How to Answer a 4.8 Rejection in Resolution Center
If you already received the rejection rather than catching it before submission, treat it like any other App Review message: answer the specific thing cited, in one reply, in Resolution Center.
- Confirm which social login triggered it. The rejection message usually names the provider your app used without an Apple equivalent.
- State plainly what you changed: that you added Sign in with Apple with equal prominence and matching data collection, and resubmit a new build rather than replying with words alone.
- If you believe your app qualifies for an exemption, say which one and why, referencing your app's actual account model. A vague claim of exemption without specifics reads the same as ignoring the guideline.
The general pattern for answering any Resolution Center message, including how App Review Information and demo credentials factor in, is covered in [Guideline 2.1 Information Needed](/blog/guideline-2-1-information-needed-rejection).
Short, practical drops on app ideas, validating fast, store listings, and passing app review. No spam, unsubscribe anytime.
Frequently asked questions
What is a Guideline 4.8 rejection?
Guideline 4.8 is Apple's Login Services rule. App Review cites it when your app offers a third-party or social login, such as Google or Facebook, to set up or authenticate a user's primary account, without also offering Sign in with Apple as an equally prominent option. The fix is to add Sign in with Apple next to your existing login options, not to remove the social login.
Do I need Sign in with Apple if I only use email and password?
No. Guideline 4.8 is triggered by offering a third-party or social login service. If your app has its own email-and-password accounts with no outside provider involved, the requirement does not apply.
Is Sign in with Apple required on Android?
No. This is an Apple App Store requirement only. Google Play has no equivalent rule, so an Expo app shipping to both stores can keep its existing social login buttons on Android untouched and add Sign in with Apple to the iOS build alone.
How do I add Sign in with Apple to an Expo app?
Enable the Sign In with Apple capability on your App ID in your Apple Developer account, install expo-apple-authentication as a config plugin so EAS Build writes the entitlement automatically, request only name and email as scopes, and support Apple's private relay email through your existing email pipeline. Test on a real device signed into a real Apple ID before you submit.
What is Apple's private relay email and do I have to support it?
It is a randomly generated address Apple lets a user share instead of their real email when they use Sign in with Apple. Yes, you have to support it. Your backend needs to accept and send to a relay address exactly like any other email, because rejecting it defeats the privacy option Apple is requiring you to offer.
Are enterprise and education apps exempt from Guideline 4.8?
Apps that require a user to sign in with an existing enterprise or education account already issued by their employer or school are generally exempt, along with apps built as a client for one specific outside service and apps using a government or industry-backed identification system. These exemptions are narrow and reviewed at Apple's discretion, so check the current guideline text directly before assuming your app qualifies.
Last reviewed by David on August 24, 2026
