Guideline 4.8 Login Services: when you need Sign in with Apple, and when you don't

1. It "limits data collection to the user’s name and email address".
2. It "allows users to keep their email address private as part of setting up their account".
3. It "does not collect interactions with your app for advertising purposes without consent".

Until January 2024 the rule named Sign in with Apple specifically. On January 25, 2024 Apple edited it to "require an additional login service with certain privacy features" instead. In principle any provider with all three features qualifies. In practice Sign in with Apple is the option reviewers recognize instantly, and its Hide My Email relay is the most obvious way to satisfy the second point.

Another login service "is not required" in these cases, paraphrased from the guideline:

• Your own accounts only. The app "exclusively uses your company’s own account setup and sign-in systems."
• Alternative marketplaces. An alternative app marketplace, or an app distributed from one, using a marketplace-specific login.
• Education, enterprise and business apps that require signing in with an existing school or company account.
• Government or industry-backed electronic ID used to authenticate users.
• Clients for a specific third-party service, where users must sign in to their mail, social media or other account directly to get their content — a Mastodon or Gmail client, for example.

The last one is narrower than it looks. A habit tracker that offers "Continue with Google" for convenience is not a client for Google's service; it just uses Google as a login. It needs the equivalent option.

Adding the button isn't the end of it. Apps that offer Sign in with Apple are also checked against its design requirements, and the most common failure is asking again for what Apple already provided:

Apple's Human Interface Guidelines put the size rule plainly: "Make a Sign in with Apple button no smaller than other sign-in buttons, and avoid making people scroll to see the button." They also say to avoid asking for a personal email address when people supply a private relay address.

Every app that lets people create an account must also let them delete it, under Guideline 5.1.1. Sign in with Apple adds one step. 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."

That call happens on your server, so plan for it before launch. If you use a backend such as Firebase or Supabase, check whether its delete-user function revokes the Apple token or whether you have to call Apple's endpoint yourself.

1. 01

   Add Sign in with Apple

   Enable the capability in Xcode and the identifier in your developer account, and use the system button from AuthenticationServices.

2. 02

   Give it equal weight

   Same size as the other sign-in buttons, visible without scrolling, on every screen where the others appear — including sign-up.

3. 03

   Handle relay emails

   Treat @privaterelay.appleid.com addresses as normal emails. If you send email, register your sending domain for Apple's relay service.

4. 04

   Remove the follow-up form

   Don't ask for the name or email again after sign-in.

5. 05

   Wire up token revocation

   Make account deletion revoke the Apple token on your server.

Hello App Review team,

Thank you for the feedback on Guideline 4.8.

Build [number] adds Sign in with Apple as an equivalent option to
Google Sign-In:
- It appears on the welcome and sign-up screens, the same size as the
  Google button and visible without scrolling.
- The app accepts private relay email addresses and does not ask for
  name or email after sign-in.
- Deleting the account (Settings > Account > Delete) revokes the
  Sign in with Apple token.

Thank you,
[Name]