App Store Guideline 4.8 Login Services: How to Fix It (2026)

What the rejection typically looks like

Guideline 4.8 - Design - Login Services

The app uses a third-party login service, but does not appear to offer an equivalent login option with the following features:
- limits data collection to the user's name and email address
- allows users to keep their email address private
- does not collect interactions with the app for advertising purposes without consent

Next Steps
Revise the app to offer an equivalent login option that meets all of the above requirements. If the app already includes such an option, reply to App Review in App Store Connect, identify it and explain why it meets the requirements.

Note that Sign in with Apple meets the requirements specified in guideline 4.8.

Paraphrased example – the exact wording in your message may differ.

What Guideline 4.8 actually requires

Guideline 4.8 applies when your app lets people set up or sign in to their primary account with a third-party or social login. Apple's examples are Facebook Login, Google Sign-In, Log in with X, Sign In with LinkedIn, Login with Amazon and WeChat Login. If you offer one of these, you must also offer another login service as an equivalent option, and that service must:

limit data collection to the user's name and email address;
let users keep their email address private while setting up the account;
not collect interactions with your app for advertising purposes without consent.

Apple defines the primary account as the one people establish "for the purposes of identifying themselves, signing in, and accessing your features and associated services" (App Store Review Guidelines, 4.8). A Google button that only connects Google Drive for a file import is therefore not a primary-account login.

Apple also marks 4.8 as a Notarization Review guideline, so it applies to notarized iOS and iPadOS apps distributed outside the App Store (through alternative app marketplaces or web distribution, where Apple allows them), not just to App Store apps.

What changed in January 2024

Until early 2024, the guideline named Sign in with Apple itself as the required equivalent option. On January 25, 2024, Apple announced that developers can offer Sign in with Apple or an equivalent privacy-focused login service. The three criteria above follow the current guideline text. Check the official guideline before each release, because Apple revises the guidelines periodically.

What qualifies in practice

Login option	Counts as the equivalent option?
Sign in with Apple	Yes. Users can share a private relay address, and Apple states it doesn't use Sign in with Apple to profile people or their activity in apps.
Google, Facebook, X, LinkedIn	No. These are the logins the rule is about, and they typically share the user's real email address.
Your own email and password next to social logins	Probably not. A standard form gives users no way to keep their email private.
Phone number and SMS code next to social logins	Probably not. A phone number goes beyond name and email.

The last two rows are our reading of the three criteria, not an explicit Apple list. 4.8 rejection messages that developers have posted end with the sentence "Note that Sign in with Apple meets the requirements specified in guideline 4.8", so Sign in with Apple is the option with the least room for debate.

Common reasons apps get rejected under 4.8

Google or Facebook buttons, no Sign in with Apple. The classic case. It often happens when an update adds "Continue with Google" to an app that already passed review many times.
Sign in with Apple only on some screens. It appears on the login screen but not on sign-up, on the account sheet behind a paywall or in a checkout flow where Google is offered.
The option is hidden or downgraded. It sits behind a "More options" link, below the fold or is visibly smaller than the Google button.
Demanding the real email afterwards. The user picks Hide My Email and onboarding then insists on a "real" address or phone number. That defeats the private-email criterion, and mandatory extra fields can also trigger Guideline 5.1.1 Data Collection and Storage.
Relying on email/password as the "equivalent". A developer on the Apple Developer Forums reported a 4.8 rejection for an app that offered manual email sign-up next to Google and Facebook.
A broken flow. A missing capability in the provisioning profile, a misconfigured Services ID or a backend that rejects Apple's identity token, so the reviewer sees an error.
Cross-platform builds that hide the button. A shared Flutter or React Native screen where the Apple button sits behind a platform check that fails on iPad, or a feature flag that was off in the review build.

Rejected or stuck? Talk to an App Specialist – for free.

Book a free consultation call: we look at your rejection or setup, explain the fastest way forward and tell you honestly whether you need us. Prefer to hand it off? Book our AI-powered + human-powered service and we take care of it.

Free consultation call Book our service →

Exceptions: when you do not need another login option

Apple lists five cases where no additional login service is required:

Your app exclusively uses your company's own account setup and sign-in systems, for example email and password, magic links, passkeys or SMS codes you run yourself. Removing the Google and Facebook buttons is therefore a legitimate fix. Existing users who signed up with Google then need a migration path, such as a password reset or magic link to the same email.
Alternative app marketplaces, or apps distributed from one, that use a marketplace-specific login for account, download and commerce features.
Education, enterprise or business apps that require the user to sign in with an existing education or enterprise account, such as staff signing in with their company directory account. Internal apps for managed devices can fall here if the company account is the only way in.
Government or industry-backed citizen identification or electronic ID, such as national eID schemes.
Clients for a specific third-party service where users must sign in to their mail, social media or other third-party account directly to access their content.

Two nuances trip people up. The enterprise exception requires an existing organization account, so a consumer app offering "Sign in with Microsoft" next to Google doesn't qualify. And if a third-party login only connects an external service (contacts import, calendar sync) while the primary account is your own, 4.8 doesn't apply to that connection.

If you rely on an exception, explain it in the Notes field under App Review Information in App Store Connect before you submit.

How to fix a 4.8 rejection step by step

Pick your path. Add Sign in with Apple (the usual fix), remove third-party logins for the primary account, or document an exception you can explain in one sentence.
Enable the capability. In Certificates, Identifiers & Profiles, enable Sign in with Apple on your App ID. In Xcode, open the target's Signing & Capabilities tab, click + Capability and add Sign in with Apple. This adds the com.apple.developer.applesignin entitlement (an array containing Default). Regenerate provisioning profiles; with fastlane match, re-run it so CI signs with the new capability.
Add the native button. Use ASAuthorizationAppleIDButton (UIKit) or SignInWithAppleButton (SwiftUI) from AuthenticationServices and request only the .fullName and .email scopes.
Verify on your server. Send the identity token and authorization code to your backend, verify the identity token and validate the authorization code at Apple's /auth/token endpoint. Store the token response, including the refresh token for later revocation, and key the user on the stable sub identifier, not the email.
Save name and email on the first authorization. Apple delivers them in the credential only the first time; on later sign-ins those fields come back empty.
Respect the private relay. Don't ask a Hide My Email user for another address, and don't make Sign in with Apple users create a password. To email relay addresses, register your sending domains or addresses in Certificates, Identifiers & Profiles under Services > Sign in with Apple for Email Communication > Configure. Outbound mail must pass SPF and/or DKIM.
Reach parity on every entry point. Wherever Google or Facebook appear, show Sign in with Apple at the same size or larger.
Handle deletion. When a user deletes their account, revoke their Apple tokens via the /auth/revoke endpoint and observe credentialRevokedNotification in the app (see Apple's technote TN3194). Missing revocation can lead to a follow-up rejection under Guideline 5.1.1(v) Account Deletion.
Test like a reviewer. Fresh install on a physical iPhone and iPad, an Apple Account that never used your app, Hide My Email selected. Then sign out, sign in, cancel once and delete the account.
Update screenshots if needed. If your App Store screenshots show the old login screen, replace them. A 4.8 rejection message posted on the Apple Developer Forums asked for exactly that.
Upload a new build and reply to App Review using the template below.

Sign in with Apple button design rules

App Review looks at the button itself, not just the flow. Apple's Human Interface Guidelines for Sign in with Apple set the rules:

Prominence: no smaller than other sign-in buttons, and visible without scrolling. The HIG doesn't prescribe a button order.
Titles: "Sign in with Apple", "Sign up with Apple" or "Continue with Apple", used consistently.
Styles: black on white or light backgrounds, white on dark backgrounds, and white with outline on light backgrounds where a white fill lacks contrast.
Size: at least 140 × 30 pt with a margin of one tenth of the button height. The corner radius may match your other buttons, from square to capsule.
Custom buttons: allowed, for example to align logos across provider buttons or to show a logo-only button, but people must instantly recognize them. Use only the Apple logo artwork from Apple Design Resources, keep logo and title black or white, and place the logo inside a button rather than using the bare logo as the button. App Review evaluates all custom Sign in with Apple buttons.

The system button handles localization, VoiceOver and proportions for you, so it is the safest choice. Cluttered login layouts can additionally attract Guideline 4.0 Design feedback.

Flutter, React Native and Expo implementation notes

Flutter

The sign_in_with_apple package offers SignInWithApple.getAppleIDCredential() with the AppleIDAuthorizationScopes.email and fullName scopes, plus a SignInWithAppleButton widget. Add the capability to the Runner target in Xcode so it lands in Runner.entitlements.
With Firebase Auth, signInWithProvider(AppleAuthProvider()) is the simplest route. If you pass an Apple identity token to Firebase manually, send the SHA-256 hash of a random nonce to Apple and the raw nonce to Firebase, or sign-in fails. For account deletion, Firebase offers revokeTokenWithAuthorizationCode().
Check that the user's name actually lands in your user record after the first sign-in, because Apple won't send it again.

React Native and Expo

Bare React Native: @invertase/react-native-apple-authentication provides appleAuth.performRequest() with the FULL_NAME and EMAIL scopes and an AppleButton component.
Expo: install expo-apple-authentication, set ios.usesAppleSignIn to true in your app config, render AppleAuthenticationButton and call signInAsync(). Gate it with isAvailableAsync() rather than a hand-written check that might hide it on iPad. The module is Apple-platform only, and Expo's docs note that fullName and email are only returned on the first sign-in.

Android and web parity

Apple doesn't require Sign in with Apple in your Android app. But a user who signed up on iPhone with a hidden relay address needs a way into their account on Android or the web. Offer the web-based Sign in with Apple flow there (Services ID plus registered return URL; the invertase library also covers Android) or let users link a password or passkey to their account.

How to reply to App Review or appeal

In App Store Connect, go to Apps, select your app and click the link at the top of the page that indicates unresolved issues. In the In Progress section, click Resolve next to the submission, then Reply to App Review. Replies can be up to 4,000 characters, and Attach File lets you add screenshots.

You fixed it

Upload the new build, then reply briefly: what you added, on which screens and how to test it. Attach a screenshot of the login screen. If your app requires an account, confirm the demo credentials in App Review Information still work, or you may trade 4.8 for a 2.1 Information Needed request.

You believe an exception applies

Reply without a new build and name the exception explicitly, for example: "This is an enterprise app. All users sign in with their employer's existing company directory account, and there is no public sign-up." Short, verifiable facts work better than arguments about intent.

If App Review still disagrees, you can appeal to the App Review Board through Apple's appeal form. Apple asks you to give specific reasons why the app complies, to submit only one appeal per rejected submission and to answer any open requests for information first. Don't claim your email/password login is the equivalent option unless users can really keep their email private; reviewers test the flow.

How to prevent 4.8 rejections in future releases

Treat new login SDKs as release-blocking. Make Sign in with Apple part of the same ticket that adds a social login.
Add a CI gate. If Podfile.lock, pubspec.lock or package-lock.json contains a social login SDK (for example GoogleSignIn, FBSDKLoginKit or google_sign_in), fail the pipeline unless the built app's entitlements, printed with codesign -d --entitlements - YourApp.app, include com.apple.developer.applesignin. Apps that rely on an exception can be allowlisted.
Snapshot the login screens on the smallest supported iPhone and on iPad to catch a hidden or undersized Apple button.
Keep review notes current with your login options and any exception you rely on.

AI-assisted pre-submission checks help here: they can flag a social login SDK without a matching entitlement, compare button sizes across screenshots and spot onboarding steps that ask for an email after Sign in with Apple. A human still has to judge edge cases such as exceptions. For a second pair of eyes before resubmitting, book a free consultation call with appsubmitter.io, or have these CI/CD checks and the submission handled for you via the order wizard.

Template: how to reply to App Review

Adapt this template to your situation. Keep it factual, short and specific – and only claim what you have actually changed.

Hello App Review Team,

Thank you for reviewing [App name], version [x.y] (build [number]).

Regarding Guideline 4.8 - Login Services: we have added Sign in with Apple as an equivalent login option. It appears on [screens, e.g. welcome, sign-up and login screen], [above / next to] the [Google / Facebook] buttons and at the same size.

Sign in with Apple requests only the user's name and email address. Users who choose Hide My Email can complete sign-up without being asked for another email address.

To test: install build [number], tap "Sign in with Apple" on [screen] and complete the flow with any Apple Account. A screenshot of the updated login screen is attached.

Best regards,
[Your name]
[Company]

Checklist before you resubmit

Every screen offering Google, Facebook or another social login also offers Sign in with Apple.
The Apple button is at least as large as the other provider buttons and visible without scrolling on small iPhones and on iPad.
Sign in with Apple is enabled on the App ID and present in the shipped build's entitlements.
Only the name and email scopes are requested, and both are saved on the first authorization.
A Hide My Email user can finish onboarding without entering another email address, a phone number or a password.
The backend validates Apple identity tokens and authorization codes and stores the refresh token keyed by the stable user identifier.
Account deletion revokes the Sign in with Apple tokens and returns the app to a signed-out state.
Sign up, sign out, sign in, cancel and delete were tested with a fresh install on a physical device.
App Store screenshots no longer show an outdated login screen.
App Review Information has working demo credentials and a note on your login options or exception.

Frequently asked questions

Is Sign in with Apple mandatory if my app uses Google Sign-In?

Not by name since January 2024. Guideline 4.8 now asks for an equivalent option that limits data to name and email, lets users hide their email and doesn't collect interactions for advertising without consent. Sign in with Apple meets all three, and Apple's own rejection messages say so. The alternatives are dropping the third-party login or qualifying for one of Apple's exceptions.

Does email and password login count as the equivalent login option?

Probably not, because a standard email/password form gives users no way to keep their email private. If your app uses only your own email/password system with no social logins, Guideline 4.8 doesn't apply at all.

Does the Sign in with Apple button have to be the first button?

Apple's Human Interface Guidelines don't require a specific order. They do require the button to be no smaller than other sign-in buttons and visible without scrolling. Placing it at the same size directly next to or above Google is the safest layout.

Do I need Sign in with Apple in my Android app or on my website?

Apple doesn't require it there, and Google Play has no such rule. However, users who signed up on iOS with a private relay address need a way to reach their account elsewhere, so offering the web-based Sign in with Apple flow or account linking prevents locked-out users.

My app only uses Google to connect Google Drive or Calendar. Does 4.8 apply?

No, as long as that connection isn't used to set up or authenticate the user's primary account. If a reviewer misreads the integration, explain that the primary account uses your own sign-in system and Google is only an optional data connection.

Do I need to revoke Sign in with Apple tokens when users delete their account?

Yes. Apple's account deletion guidance says apps that support Sign in with Apple should use the Sign in with Apple REST API to revoke user tokens. Do it server-side, delete the user's data and return the app to a signed-out state. Our account deletion guide covers the details.

Official source: App Store Review Guidelines – 4.8 Login Services. Store policies change regularly – always check the current version. This guide is independent advice and not affiliated with Apple or Google.

Guideline 4.8 Login Services: how to fix a Sign in with Apple rejection