Add Google Sign-In to your iOS app and you have also agreed to ship a second login. That is the effect of App Review Guideline 4.8: "Apps that use a third-party or social login service (such as Facebook Login, Google Sign-In, Log in with X, Sign In with LinkedIn, Login with Amazon, or WeChat Login) to set up or authenticate the user's primary account with the app must also offer as an equivalent option another login service" that meets three privacy tests.
The rule is known as the Sign in with Apple rule, but it has not named Sign in with Apple since January 25, 2024. What it requires now, what it exempts, and what passes review is what this post covers.
What the rule demands
The required second login has to satisfy all three of these, quoted as written:
- "the login service limits data collection to the user's name and email address"
- "the login service allows users to keep their email address private as part of setting up their account"
- "the login service does not collect interactions with your app for advertising purposes without consent"
A "primary account" is defined in the same paragraph: "the account they establish with your app for the purposes of identifying themselves, signing in, and accessing your features and associated services." Read plainly: the account your app actually uses. The named login list is illustrative ("such as"), not exhaustive. Any OAuth provider, any social button, same trigger.
Who is exempt
The guideline lists five cases where no second login is required:
- your app exclusively uses your company's own account setup and sign-in systems
- alternative app marketplaces, and apps distributed from one, using a marketplace-specific login
- education, enterprise, or business apps that require an existing education or enterprise account
- apps using a government or industry-backed citizen identification system or electronic ID
- clients for a specific third-party service, where users must sign in to that account directly to reach their content
The first one does the most work. Email-plus-password plus Google Sign-In is not "exclusively" your own system, so the combination still triggers the rule. There is a live, unresolved debate about whether your own login could itself count as "another login service" if it met the three tests. We would not ship an app on that argument; App Review is where interpretations go to die.
What changed in 2024
Until January 2024 the text named the product: apps "must also offer Sign in with Apple as an equivalent option." Apple's announcement on January 25, 2024 softened that: "developers that offer third-party or social login services within their app will have the option to offer Sign in with Apple, or they will now be able to offer an equivalent privacy-focused login service instead." A March 5, 2024 revision added the advertising-data clause and the marketplace exception.
On paper, any service meeting the three tests now qualifies. In review, the expectation has not moved. A rejection message posted on Apple's developer forums reads: "The app uses a third-party login service like Google or Facebook, but does not appear to offer an equivalent login option with Sign in with Apple. [...] Note that Sign in with Apple meets the requirements specified in guideline 4.8." Reviewers treat Sign in with Apple as the reference implementation, and building a custom private login to satisfy the letter of the rule means arguing scope with the person holding your release.
What the private option actually is
Sign in with Apple satisfies all three tests by design, which is why it remains the practical answer. Per Apple's support page, apps "can ask only for your name and email address" at first sign-in, and "Sign in with Apple won't track or profile you as you use your favorite apps and websites." The second test maps to Hide My Email, Apple's relay that generates unique, random addresses forwarding to the user's real inbox, so the app gets a working email without getting the real one.
Mechanically it is an OAuth 2.0 / OpenID Connect flow: Apple does not market it that way, but the OpenID Foundation tracked it as an OIDC implementation and Apple's discovery document is live at appleid.apple.com/.well-known/openid-configuration. It works on Android and the web too, not just Apple platforms, per Apple's own HIG. There is no per-use fee, though the capability requires the paid Apple Developer Program membership.
The other store does not care
Google Play has no equivalent rule. Play's only sign-in requirement is operational: if your app needs credentials, you must provide working sign-in details so reviewers can reach every feature. No mandate on which providers you offer, no private-email alternative. Your Android build can ship Google login alone; the private option is an App Store tax.
Our position
Treat rule 4.8 as part of the scope the moment a social login appears in the spec. Sign in with Apple is the option to ship: it passes the three tests by construction, reviewers already expect it, and the Hide My Email flow is a UX users recognize rather than a privacy feature you have to explain. One follow-on obligation worth knowing: for accounts created through Sign in with Apple, deleting the account means revoking the user's tokens with Apple's REST API, which we covered in the account deletion post.
The takeaway
Run this against your app's sign-in screen:
google, facebook, x, linkedin, amazon, wechat, or any oauth
or matches one of the four other listed carve-outs
private email, and does not feed ad tracking
what reviewers expect; a custom equivalent is a scope fight
on account deletion via apple's rest api
Login requirements are the kind of store rule our custom software builds account for in the first spec, not the week before submission. If your sign-in screen is one social button and you want it through review, send us the app.
// sources
// next step
We work this way on client projects too.
Tell us what you are making. We reply with a plan, a timeline, and a price.
