An iOS app that offers Google, Facebook, or another social sign-in may need to provide an additional login option before App Review. The trigger is specific: the third-party or social service sets up or authenticates the user’s primary account in the app. Apple’s guideline 4.8 then calls for an equivalent login service with three privacy features.
That wording is narrower than “every app must add Sign in with Apple.” The practical work is to map each sign-in path to the account it creates, check the guideline’s exact criteria, and confirm whether one of the listed exceptions applies. Do this before review, while account flows can still be changed without disrupting existing users.
Check which account the login authenticates
Start with the account the person uses to identify themselves, sign in, and access the app’s features and services. Apple defines this as the user’s primary account. A social provider used to authenticate that account is within the scope described by guideline 4.8.
Draw the real paths a new and returning user can take. Include registration, sign-in, account linking, recovery, and any login that appears only after a feature is selected. A button’s label is not enough to classify it: determine whether it authenticates the app’s primary account or gives access to a separate third-party service.
For example, a social login that creates an account for a fitness app is different from a mail client that asks the user to sign in directly to the mail provider to access that provider’s messages. Apple lists the latter type of client as an exception. If your app combines both patterns, document which account each option accesses rather than treating every provider button alike.
Apply the three criteria as written
When the guideline applies, the additional login service must meet all three listed features:
- It limits data collection to the user’s name and email address.
- It lets users keep their email address private while setting up the account.
- It does not collect interactions with the app for advertising purposes without consent.
Treat these as separate checks. A provider that requests only a small set of profile data may still fail the private-email criterion. A private relay address alone does not establish how the service handles app interactions for advertising. Record evidence for each point, including the provider’s current documentation and the behavior of your own integration.
Sign in with Apple is a common implementation to evaluate because Apple documents a private email option. The guideline itself is written in terms of an equivalent login service and its features, so assess the actual option you offer against the criteria instead of relying on a label. Avoid assuming another provider qualifies just because it supports OAuth or returns an email address.
Check whether an exception fits your app
Apple lists cases where another login service is not required. These include an app that exclusively uses the company’s own account setup and sign-in systems; certain alternative app marketplaces; education, enterprise, or business apps that require an existing organization account; government or industry-backed citizen identification systems; and a client for a specific third-party service where users must sign in to that service to access its content.
Read the full exception wording and match it to the product’s actual purpose and login flow. A company account by itself is not enough to claim the enterprise exception: the guideline refers to an app that requires an existing education or enterprise account. Likewise, an app that has its own password login plus social login is not exclusively using its own account system.
Do not infer an exception from the audience you hope to attract or from a single screen. Note the applicable exception, what the app does, and which login path it covers. If none fits clearly, plan for the three criteria rather than building the release around an assumption.
Review every entry point and account state
A login audit should cover more than the first screen. List each entry point: onboarding, gated features, settings, account recovery, and links from invitations or notifications. For each, capture the options shown and whether the person is creating an account, authenticating an existing primary account, linking another provider, or entering a third-party service.
Then walk through the states that affect behavior:
- A new person chooses each available sign-in option.
- An existing person returns with the same provider.
- A person tries to link a second sign-in method to an existing account.
- A person cancels the provider flow or returns without granting optional data.
- A person changes or hides the email address shared during account setup.
- A person requests account recovery or deletes the account.
This review helps expose implementation issues that a static mockup will not show. For example, the app may treat a private relay address as a separate user, or a returning user may lose access if the account lookup assumes a personal email. These are design risks to test in your own system, not claims about a particular identity provider.
Plan account linking before adding a second button
Adding a login choice can affect account identity. Decide how your backend associates provider identifiers with an app account, how a user can link or unlink a method, and what happens when the same person presents a different email later. Do not use an email address as the only permanent identity key if the product needs to support multiple login methods or private email choices.
Before implementation, write down the expected result for each case: create a new account, sign in to an existing account, offer a safe link flow, or ask the user to resolve a possible duplicate. Make sure account recovery remains available when an optional provider is unavailable. Do not silently merge two accounts because their email strings happen to match.
For existing apps, consider how a new option affects people who already use social sign-in. Preserve access to their data and subscriptions during migration. Explain the change in the product, provide a clear linking path where needed, and test the transition with accounts that have different email-sharing choices. Keep the implementation’s behavior consistent across app versions if a user may sign in from more than one device.
Prepare a reviewable explanation
If guideline 4.8 applies, make the equivalent option easy to find alongside the relevant third-party or social login. Verify the visible button, its interaction, the account created, and the privacy choices in a release build. Include enough context in the App Review notes for a reviewer to reach the login flow and understand any non-obvious behavior. Apple separately asks developers to provide full access to account-based features and to explain non-obvious features in review notes.
If you believe an exception applies, prepare a concise explanation tied to the specific exception and the app’s actual flow. Keep it factual: name the screen, describe what account is used, and explain why the listed exception matches. That makes your decision easier to revisit when the product or its login paths change.
For a wider iOS submission pass, see our App Store submission checklist for AI-built apps. For guideline 4.8 itself, check section 4.8 in Apple’s current App Review Guidelines immediately before submission; the document can change.
Release checklist
Before sending an iOS build to review, confirm:
- Each login button is mapped to the account and content it authenticates.
- You know whether any third-party or social option creates or authenticates the primary app account.
- If guideline 4.8 applies, the additional option meets all three privacy criteria.
- Any claimed exception matches the exact wording and the product’s real purpose.
- New, returning, linked, canceled, and recovery flows have been exercised.
- Private email choices do not break account lookup or support.
- Existing users keep their accounts and entitlements through any login change.
- App Review can reach account-based features, and the review notes explain any non-obvious flow.
The decision is not simply whether an app has a social-login button. It is which account that button authenticates, what privacy properties the alternative option provides, and whether an exception fits the app. Capture that reasoning while the flow is being designed, then verify it in the build you submit.
Top comments (0)