Add social login to an app and Apple will ask for a second button.
To add social login to an app you drop a provider SDK into the sign-in screen, hand the token it returns to your backend, and create or match a user record. That part is an afternoon. What decides your release date is App Review guideline 4.8, which says an app using a third party login for someone's primary account has to offer an equivalent option that meets three privacy conditions. If the ordinary version is not built yet, start with adding user login, because a social button is a second door into an account system you still have to own.
Below: what 4.8 actually requires and the five cases it exempts, which providers earn their place, why an OAuth login in a mobile app has to run outside your own code, and the account linking and email relay work that nobody budgets for.
Check whether the rule applies to youThe short version
The button takes an afternoon. The rules around it take the week.
Every provider ships a drop-in SDK and a sample screen. Getting a Sign in with Google button to return a token is not where projects stall.
They stall on the second login option a reviewer looks for, on mail that bounces off Apple's private relay because the sending domain was never registered, and on the user who signed up with Google in March, tapped Sign in with Apple in June and landed in an empty account.
What guideline 4.8 actually requires
The rule is usually repeated as "Apple requires Sign in with Apple". That is not what it says. Guideline 4.8 says an app that uses a third party or social login service to set up or authenticate a user's primary account must also offer, as an equivalent option, another login service that limits data collection to the user's name and email address, lets people keep that email address private as part of setting up the account, and does not collect interactions with the app for advertising purposes without consent.
The wording matters because it describes a test, not a product. Sign in with Apple passes all three conditions, which is why almost everyone uses it and why the shorthand stuck. Whether a plain email and password sign-up passes depends on the second condition, keeping the address private, and we did not find Apple stating a position on that anywhere in the guidelines. Treat Sign in with Apple as the option known to satisfy the rule and anything else as a question for App Review.
Five cases are exempt, written into the guideline itself: an app that exclusively uses your own company's account setup and sign-in; an alternative app marketplace, or an app distributed from one, using a marketplace login; an education, enterprise or business app that requires an existing education or enterprise account; an app using a government or industry backed citizen identification system or electronic ID; and an app that is a client for one specific third party service where people sign in to their own mail, social or other account to reach their content. Outside those five, plan for the second button.
App Store Review Guidelines, 4.8 Login Services
Try it
Does guideline 4.8 apply to your app?
Tick anything that is true. The five exemptions below are the ones written into the guideline, not a summary of them.
A second login option is required
Offer an equivalent login service that collects only name and email address, lets people keep that address private while setting up, and does not collect in-app interactions for advertising without consent. Sign in with Apple meets all three.
Which providers are worth putting on the screen
Three buttons is usually one too many. Each provider is another console, another set of credentials per platform, another thing that breaks when a key rotates, and one more branch in your account matching code. Choose on where your users already are, not on completeness.
On iOS, Sign in with Apple is the floor rather than a choice, because the moment you add anything else the rule above applies. Sign in with Google earns its place if your users are on Android or already inside Google Workspace, and it needs an OAuth client registered for every platform you ship. Facebook Login only earns its place if you know your audience is there, and it brings a review process of its own with Meta. Everything past the second button tends to be decoration.
The provider list is a smaller decision than what you do with the result. Sessions, refresh tokens and where you keep them are the same problem whether the password came from your database or from Google, and that is the subject of app authentication. Social login replaces the password. It does not replace the session.
The flow that works and the one that gets blocked
The authorization page has to open in the system browser, not in a webview your app draws. Google's documentation for installed apps puts it plainly: the app opens the system browser and supplies a local redirect URI to handle the response. An authorization request made inside an embedded user agent is refused with a disallowed_useragent error, and for iOS the guidance is to use the Google Sign-In SDK or the OpenID Foundation's AppAuth library, with SFSafariViewController listed as a supported option.
This is not the platform being awkward. In an embedded webview your app is drawing the password field and the user cannot see an address bar telling them whose page it is. The same page notes a related consequence: incremental authorization is not supported for installed apps, because the client cannot keep the client secret confidential. A secret shipped inside an app is not a secret, so never design a flow that depends on one staying hidden.
After the redirect comes the part that actually protects the account. Exchange the code and verify the identity token signature on your server, and never trust a user identifier that arrived from the client on its own. If that sentence is new, read app security basics before you call the login screen finished.
One person, three buttons, one account
The bug you will ship is the duplicate account. Somebody signs up with Google, comes back months later, taps the Apple button and lands in an empty account carrying the same email address. Decide before launch whether the email address is the identity key, what happens when two providers return the same one, and whether a signed-in user can attach a second provider to the account they already have.
Apple makes this harder in two specific ways. The name comes back only when the user approves the request, and Apple's documentation describes that request happening the first time someone logs in, so store it on that first response; recovering it later means the user revoking your app in their Apple Account settings and signing in again. And if they choose Hide My Email you get a privaterelay.appleid.com address that bounces your mail unless you have registered the sending domain in the developer portal with a matching SPF record. An individual account can register up to 32 email sources and an organization up to 100.
So the honest cost of social login is not the button. It is one more identity to reconcile, an address you may never see, and a support path for the person who cannot remember which button they pressed last time. Get the account model right and the buttons become the easy part.
What each login option costs you
| Login option | Satisfies 4.8 as the second option | Works on Android | User can hide their address | Setup beyond the SDK |
|---|---|---|---|---|
| Sign in with Apple | Yes | through the web flow | Yes | Apple Developer account, relay domains and SPF |
| Sign in with Google | No | Yes | No | an OAuth client per platform |
| Facebook Login | No | Yes | No | a Meta app review |
| Email and password | unconfirmed | Yes | only if you accept aliases | reset and verification flows |
| Magic link or one-time code | unconfirmed | Yes | No | email or SMS delivery you pay for |
Building the sign-in screen without building an identity service
There is a real build-or-buy line here and it is not where people draw it. A hosted identity provider sells you the provider integrations, the token handling and the account linking, priced per monthly active user, and gives you account linking as a feature rather than as a project. Writing it yourself is an afternoon for the button and a long tail for everything after it. The thing worth paying for is the account model, not the button.
Newly is an AI app builder. You describe the app in plain English, it writes a real React Native and Expo project you own, runs it on a cloud iPhone or Android simulator while it builds, and ships to TestFlight and to Google Play internal testing. It is $25 a month and there is no free plan. It does not run an identity service of its own, so which provider and which backend sit behind your login screen stays your decision rather than a default you inherit.
That matters more than it sounds. Because a project built with Newly comes out as a repo you own, through two way GitHub sync or a ZIP, swapping a provider a year from now is a code change rather than a migration off somebody's platform. The login screen is also not the last gate before release: your privacy details have to match what the providers actually collect, and an account deletion path has to exist. That is a separate checklist, covered in what Apple requires.
Questions people ask about social login
Not in those words. Guideline 4.8 says an app using a third party or social login for the user's primary account must also offer an equivalent login service that limits data collection to name and email address, lets people keep that address private while setting up, and does not collect in-app interactions for advertising without consent. Sign in with Apple meets all three, which is why it is the usual answer, but the guideline describes a test rather than naming a product.
Describe the sign-in your app actually needs
Write down which buttons you want, which one is the fallback, and what should happen when the same person uses both, then build the screen around that.
Start building