Sign in with Apple: when it is required and how to test it

If your iOS app offers Google, Facebook or any other third-party login, App Store guideline 4.8 expects Sign in with Apple or an equivalent privacy-focused option too. This guide explains when the rule applies and when it does not, the parts of the flow that break most often (Hide My Email, missing names, revoked credentials, account linking), and a test task your AI beta tester can run on a real iPhone.

Who it’s for

  • iOS developers adding social login before an App Store submission
  • Teams rejected under guideline 4.8 Login Services
  • Backend developers validating Apple identity tokens and relay emails
  • Cross-platform teams that need Sign in with Apple on Android and the web as well

Updated 2026-10-25.

When Sign in with Apple is required

App Store Review Guideline 4.8 (Login Services) says that apps using a third-party or social login service to set up or authenticate the user's primary account must also offer a login option with these privacy features:

  • It limits data collection to the user's name and email address.
  • It lets users keep their email private as part of account setup.
  • It does not collect interactions with the app for advertising without consent.

Sign in with Apple meets those conditions, and since Apple's own text now allows "an equivalent" service, other privacy-preserving options may qualify. In practice most teams add Sign in with Apple because it is the safest reading and users expect it.

Verify the current wording before you decide. The guideline has been revised more than once, and the exceptions below are summarized, not quoted.

When it is not required

Guideline 4.8 lists exceptions. Your app does not need Sign in with Apple if it:

  • Uses only its own account system (email and password, phone number codes) with no third-party login.
  • Is an education, enterprise or business app that requires users to sign in with an existing education or enterprise account.
  • Uses a government or industry-backed citizen identification system or electronic ID.
  • Is a client for a specific third-party service and users must sign in to that service directly (for example, a client for a specific email or social network).

If you add a Google button later, the requirement switches on. Review the login screen on every release.

How Sign in with Apple works

  1. The user taps the Sign in with Apple button (Apple has rules about its appearance in the Human Interface Guidelines).
  2. The system sheet confirms with Face ID, Touch ID or the passcode and asks whether to share or hide the email.
  3. Your app receives an identity token (a JWT), an authorization code, a stable user identifier, and, on the first authorization only, the user's name and email.
  4. Your server verifies the token against Apple's public keys and creates or links the account.
  5. On later sign-ins your app receives the user identifier and token but no name or email, so you must have stored them the first time.

The parts that break

  • Name and email only arrive once. If your signup fails after the first authorization, the user is left with no name and no email in your system. Store them before anything else, and provide a way to add a name later.
  • Hide My Email relay. Users can choose a private relay address (ending in privaterelay.appleid.com). Your transactional emails only reach it if your sending domains are registered in the Apple Developer portal. Marketing systems that reject or dedupe relay addresses cause silent failures.
  • Account linking. A user who signed up with email and later taps Sign in with Apple with the same email should get the same account, not a duplicate. With Hide My Email the emails differ, so offer a link accounts step inside the app.
  • Revoked credentials. Users can stop using your app with their Apple ID from Settings. Your app should listen for the credential revoked notification and sign out. Apple also expects you to revoke tokens on your side when the user deletes their account.
  • Button placement. The Sign in with Apple button must be offered where the other third-party logins are, with comparable prominence. Hiding it on a second screen is a 4.8 rejection.
  • Nonce and token validation. Validate the identity token server-side with the nonce you sent, and check the audience and expiry. Trusting the client payload is a security bug.

Sign in with Apple on Android and the web

The same account should work on every platform, so the Android app and website use Sign in with Apple JS, which opens a web flow and returns the token to your redirect URL. Test that the Apple user ID matches across platforms, that the Android flow handles the browser return correctly, and that cancellation does not leave a half-created account.

What to test

  • The button appears alongside every third-party login option, follows Apple's design rules, and works in light and dark mode.
  • First sign-in with a new Apple ID: name and email are stored; sharing the email and hiding it both create a working account.
  • Second sign-in on the same account: the user lands in the same account without being asked to sign up again.
  • Hide My Email: the welcome and password reset emails arrive at the relay address.
  • Cancel the Apple sheet: the app returns to the login screen with no error loop or ghost account.
  • Account linking: an existing email account and an Apple sign-in with the same email produce one account, or a clear link accounts prompt.
  • Revocation: revoke the app in Settings > Apple ID > Sign in with Apple, reopen the app, and confirm it signs out and can sign in again.
  • Account deletion revokes the Apple token and a later Sign in with Apple is treated as a new user.
  • Error handling: airplane mode during the sheet, and a server that rejects the token, both produce readable messages.

Testing on simulators versus real devices

Sign in with Apple works on the iOS simulator signed in with a test Apple ID, but the real device catches more: biometric confirmation, the Settings revocation path, Hide My Email with real email delivery and the behavior of the sheet after backgrounding. Apple's sandbox Apple IDs are for in-app purchase testing, not sign-in; use a real Apple ID that you control, created for testing, and expect that Apple may limit how many times you can reset the Hide My Email relationship.

Example finding

Title: Sign in with Apple creates a second account for an existing email user
Guideline at risk: 4.8 (also a data integrity issue)
Environment: iPhone 15, iOS 18.1, build 2.2.0 (301), real device

Steps to reproduce:
1. Sign up with email [email protected] and a password; add a profile name.
2. Sign out.
3. Tap "Sign in with Apple" with an Apple ID whose email is [email protected]
   and choose "Share My Email".

Expected: The app signs in to the existing account or offers to link them.
Actual: A new empty account is created with the same email. The original
profile is no longer reachable by this user.

Severity: High (data loss from the user's point of view)
Evidence: recording of steps 1-3, screenshots of both accounts.

How an AI beta tester helps

betatest.ing's Store readiness tests include a Sign in with Apple check. On your uploaded .ipa, running on a real iPhone, it checks the login screen for the button next to other social logins, runs the first and repeat sign-in with a test Apple ID you provide, tries Hide My Email, cancels the sheet, tests linking against an existing email account and checks the revocation path. Findings include steps, severity, annotated screenshots and a recording of each broken flow, and the report says whether the login screen would pass a 4.8 read. Test credentials are encrypted and never shown to the AI.

The test task

What you send your AI beta tester. It works out the steps and tests like a real user.

Test Sign in with Apple in my iOS app (the uploaded .ipa) on a real iPhone. It is [WHAT THE APP DOES]. On the login screen, confirm the Sign in with Apple button is offered wherever other third-party logins are ([OTHER LOGIN OPTIONS]) and looks correct in light and dark mode. Use the saved test Apple ID to sign in for the first time with Share My Email and check the profile has a name and email; sign out and sign in again and confirm you land in the same account. Repeat with a second sign-in choosing Hide My Email and check that the welcome email reaches the relay inbox [RELAY-CAPABLE INBOX OR 'skip']. Cancel the Apple sheet once and check the app recovers. Then sign up with email and password using the same address as the Apple ID and try Sign in with Apple again: report whether it links to the existing account, creates a duplicate, or asks to link. Finally revoke the app in Settings > Apple ID > Sign in with Apple, reopen the app and report what happens. Log each issue as a finding with steps to reproduce, severity and an annotated screenshot, record any broken flow, and end with a report that scores the login screen against guideline 4.8 with the top fixes.

Fill in your details

Here, or later in the chat with your tester.

  • [WHAT THE APP DOES] One sentence about the app and its users
  • [OTHER LOGIN OPTIONS] The social or third-party logins you offer, e.g. Google and Facebook
  • [RELAY-CAPABLE INBOX OR 'skip'] The inbox behind the test Apple ID so relay email delivery can be checked, or skip

What the AI beta tester checks

  • Sign in with Apple button present next to every third-party login, correct in light and dark mode
  • First sign-in stores name and email; repeat sign-in lands in the same account
  • Hide My Email creates a working account and emails reach the relay address
  • Cancelling the Apple sheet returns to the login screen cleanly
  • Existing email account plus Apple sign-in with the same email: linking, not duplication
  • Revoking the app in Settings signs the user out and allows a new sign-in
  • Readable errors with no network or a rejected token
  • Login screen layout on small and large iPhones

What you get

  • Findings with steps to reproduce, severity and annotated screenshots
  • Recordings of each broken sign-in or linking flow
  • A guideline 4.8 read of the login screen
  • A report with the top fixes before App Store submission

How to run it with betatest.ing

  1. Add your app as a project in betatest.ing and upload the .ipa (ad-hoc, development or enterprise export).
  2. Save a test Apple ID you control, and an email and password test account, as the project's test logins.
  3. Send the Sign in with Apple task; the tester runs it on a real iPhone.
  4. Fix the gaps, re-upload and re-run; keep the task in your pre-submission checks.

Tips

  • Store the name and email from the first authorization before any other signup step can fail.
  • Register your sending domains for the Hide My Email relay or transactional emails never arrive.
  • Offer a link accounts step for users who already have an email account.
  • Handle the credential revoked notification and revoke tokens on account deletion.
  • Re-check the login screen on every release; adding one social button turns the requirement on.

Sign in with Apple requirement: FAQ

Is Sign in with Apple mandatory for every iOS app?

No. Guideline 4.8 applies when you offer a third-party or social login such as Google or Facebook. Apps with only their own email and password or phone login, enterprise and education logins, government IDs, or clients for one specific service are exempt. Check the current text for details.

Can I use another privacy-focused login instead of Sign in with Apple?

Apple's current guideline text allows an equivalent service that limits data to name and email, lets users hide their email and does not track for advertising without consent. Most teams still add Sign in with Apple because it clearly meets the test and users expect it.

Why does my app get no email on the second sign-in?

Apple sends the name and email only on the first authorization for your app. Later sign-ins return the user identifier and token only, so your backend must store those details the first time.

What is Hide My Email and why do my emails bounce?

Users can share a private relay address instead of their real email. Apple forwards mail to the user only from sending domains and addresses you register in the developer portal, so unregistered senders fail silently.

How do I handle a user who revokes access in Settings?

Listen for the credential revoked notification and check credential state on launch, then sign the user out gracefully. When the user deletes their account, revoke the Apple tokens on your side as Apple expects.

Does Sign in with Apple work on Android?

Yes, through Sign in with Apple JS, which runs a web flow and returns the token to your redirect URL. Test that the same Apple user ID maps to the same account across iOS, Android and the web.

Can I test Sign in with Apple on the iOS simulator?

You can sign in on a simulator with a test Apple ID, but a real device also covers biometric confirmation, the Settings revocation path and real relay email delivery, so run the final check on a real iPhone.

Can an AI beta tester test Sign in with Apple?

Yes, on a real iPhone with a test Apple ID you provide. It checks button placement, first and repeat sign-in, Hide My Email, cancellation, account linking and revocation, and files findings with screenshots and recordings. Credentials are encrypted and never shown to the AI.

Related beta testing guides

  • App Store rejection reasons — Most App Store rejections are not about taste. They cite a small set of guidelines: the app crashed, a login had no demo account, a purchase bypassed in-app purchase, a social login lacked Sign in with Apple, or there was no way to delete an account. This guide lists the common rejection reasons by guideline number, what reviewers actually check, and a review-readiness task your AI beta tester can run on the build before you press Submit.
  • In-app account deletion requirement — Both app stores require apps that let users create an account to let them delete it, inside the app, for real. It is one of the most common reasons an otherwise finished app gets rejected. This page explains what Apple and Google require, how grace periods, data export and subscriptions fit in, and what to test so the deletion flow passes review and actually works.
  • Login testing — Login looks simple until a user is locked out at the worst moment. This page lists what to test in login, logout and password reset flows, the safe limits for testing them, and a ready-to-run task for your AI beta tester.
  • iOS app beta testing — TestFlight is how almost every iOS app gets into beta testers' hands before the App Store. This guide explains how TestFlight testing works, what to check on iPhone that differs from Android, and how to run an AI beta test on a real iPhone from an uploaded .ipa build.
  • iOS simulator vs real device testing — The iOS Simulator is where most iPhone development happens, but it is not an iPhone. This guide lists what the simulator handles well, what only a real device can show you, and how to split a beta test between the two, with a task your AI beta tester can run on real iPhones and simulators from an uploaded .ipa.
  • Free tool: Beta testing checklist generator — An interactive checklist for websites, SaaS, mobile apps, stores and extensions. Progress saved, Markdown export.

More in by test type