Is Sign in with Apple Required? Fixing a Guideline 4.8 Rejection

If the rejection just landed in your inbox, take a breath. This is a well-understood rejection with a clear fix. Follow the order below, and you can usually handle the code change and the reply in one round.

1. Confirm that the rejection cites Guideline 4.8 and note which screen it points to.
2. List every sign-up and login path in your app: email, Google, Facebook, phone number, and anything else.
3. Check honestly whether your app fits one of the official exemptions listed below.
4. If no exemption applies, add Apple's login or another service that meets all three privacy criteria.
5. Place the new button on the same screen as the other login buttons, at least as visible as they are.
6. Upload a new build and explain the change briefly in your reply to App Review.

This article focuses only on the 4.8 rejection. For a broader overview of review problems, see our guide on why apps get rejected most often.

What does Guideline 4.8 actually say?

You can read the current wording in the Apple App Review Guidelines. In short, an app that uses a third-party or social login service to set up or authenticate the user's primary account must also offer another login service as an equivalent option. Apple names Facebook Login, Google Sign-In, Log in with X, Sign In with LinkedIn, Login with Amazon, and WeChat Login as examples.

The second service must have all three of these 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 your app for advertising purposes without consent.

Notice that the text describes features instead of naming a specific product. Earlier versions of the rule asked for Apple's own login by name. The current version, however, opens the door to any service that meets the three criteria. That said, Apple's login remains the option that meets them most clearly. Because the rule has changed over time, always check the live guideline before you build.

What counts as a primary account?

Apple defines the primary account as the account people establish with your app to identify themselves, sign in, and access your features and associated services. In other words, the rule is about the main door into your app.

For example, imagine a photo editing app. If users sign up with Google and then access their own projects, that Google login creates the primary account, so Guideline 4.8 applies. On the other hand, if the app only connects to Google Drive to export photos, that connection is an integration, not a primary account.

Making this distinction clear also strengthens your reply. You can tell App Review something concrete, such as "the Google connection is only used for file export and does not create an account." Still, the explanation has to match the real flow in your build. Otherwise, the same rejection will come back in the next review.

Which apps are exempt from Guideline 4.8?

The official text lists five cases where another login service is not required. If you believe your app fits one of them, base your reasoning on these points:

• Your app exclusively uses your company's own account setup and sign-in systems.
• It is an alternative app marketplace, or is distributed from one, and uses a marketplace-specific login for account, download, and commerce features.
• Your app is an education, enterprise, or business app that requires users to sign in with an existing education or enterprise account.
• It relies on a government or industry-backed citizen identification system or electronic ID.
• Your app is a client for a specific third-party service, and users must sign in to that mail, social media, or other account directly to access their content.

In practice, the first exemption causes the most confusion. The word "exclusively" matters here. As soon as you add a single Google button next to your own system, you no longer qualify.

Is your own email and password login enough?

If your app only offers its own email and password registration, you do not need an additional service. The trouble starts when you offer a social login next to your own system.

Many teams then assume that their email sign-up already counts as the equivalent option. However, the guideline describes the equivalent option as "another login service" with three privacy features. It does not say that your own email form qualifies. Therefore, there is no reliable basis for expecting this argument to succeed.

Our advice is simple. In most projects, adding Apple's login is faster than arguing about it. You leave the rejection loop, and users also get an option that needs no new password. In addition, you do not have to remove your own email sign-up; all three options can live side by side.

If you still want to argue that your flow meets the rule, be ready to explain in writing how it delivers each of the three features. Even then, the outcome depends on how App Review reads it.

Which login options satisfy Guideline 4.8?

The table below compares common login setups through the lens of the rule. It is our interpretation; the final decision always rests with App Review.

The fourth row is the riskiest. Small teams often launch with exactly this combination and get rejected in the first review.

Why is Apple's login usually the fastest fix?

In theory, you could pick another service that meets the three criteria. However, proving that a service meets them is your responsibility. Apple's option already lets users hide their email, so App Review is less likely to ask for extra explanation.

Moreover, the iOS side ships with a system framework. Users create an account with Face ID or their device passcode in a single tap, so they skip the registration form. In practice, that can reduce drop-off at the sign-up step.

On the other hand, the integration has server-side work, the private email relay, and the account deletion flow. Getting all of these right the first time takes effort, and one gap can trigger a new rejection. If your team lacks that experience, our mobile app development services can help you plan the whole login flow end to end. If you prefer to build it yourself, the next sections walk through each point in order.

Where should you place the Sign in with Apple button?

Apple's Human Interface Guidelines for Sign in with Apple set clear rules for the button. Display it prominently, make it no smaller than other sign-in buttons, and avoid making people scroll to see it.

• Use only "Sign in with Apple," "Sign up with Apple," or "Continue with Apple" as the button title.
• Choose between the black, white, and white with outline styles based on your background.
• Do not use the black style on dark backgrounds, and use the outlined style on light backgrounds that lack contrast.
• Apply the same title variant consistently across every login and sign-up screen.

The most common mistake we see is hiding the Apple option under a "more options" menu. For instance, if the Google button spans the full width while Apple's option is a small icon, App Review may not consider it equivalent. So place both buttons on the same screen, at the same size, stacked one above the other.

How should you request name and email?

During the Apple flow, you can request the name and email scopes. The user can then edit their name, pick a different contact email, or hide their email entirely. If they hide it, Apple generates a unique relay address that forwards messages to their real inbox.

The design guidelines ask you to respect that choice. In other words, do not ask for a personal email after someone shares a relay address. Also, do not ask for a password, because a key benefit of this method is that people do not have to create one.

• If you need extra data such as a date of birth, keep requests to a minimum and say whether they are required or optional.
• Do not block account access or features for people who skip optional information.
• Store the name and email on your server as soon as you receive them, since later sign-ins may not return them again.

That last point matters a lot in practice. A common experience in the developer community is that these details usually arrive only on the first authorization. As a result, a server that fails to store the first response can leave the user with a nameless account.

How do you set up the private email relay?

When a user hides their email, you receive a relay address. If you want to send order confirmations or other messages there, you need to prepare on Apple's side first. According to Apple's private email relay help page, you must register and validate every domain or subdomain you send from.

1. List every domain and subdomain your app sends email from.
2. Register these sources in the relevant section of your Apple Developer account.
3. Authenticate outbound mail with SPF and, where possible, DKIM; Apple recommends using both.
4. Check that the sending domain matches the registered domain exactly.
5. Send a test message to a relay address from a test account and confirm delivery.

If you forget to register a source, messages to the relay address bounce. For example, if marketing email goes out from a separate subdomain, add that subdomain too. This step does not directly cause a 4.8 rejection; still, it hurts the user experience and increases support requests.

What happens to Apple tokens when a user deletes the account?

Apps that support account creation must also let users delete their account from within the app. We covered that rule in detail in our article on Apple's mandatory account deletion rule, so here we only cover the Apple login side.

According to the FAQ in Apple's account deletion guidance, apps that support Apple's login should use the Sign in with Apple REST API to revoke user tokens when an account is deleted. Apple also recommends using server-to-server notification endpoints to process changes to these accounts.

So plan the deletion flow at the same time as the login. Your server should store the tokens needed for revocation securely during sign-in. Otherwise, the user's authorization on Apple's side may stay active after they tap delete, and that can become a second rejection reason.

Why should you check credential state at launch?

Users can revoke your app's access from their Apple Account settings at any time. For that reason, Apple's sample code checks the state of the saved user identifier whenever the app launches.

If the state is authorized, the app continues normally. If access was revoked or the credential is not found, the app shows the login screen again. That way, a user who removed access does not stay inside with an old session.

A missing check does not always lead to a rejection on its own. Still, if a reviewer sees odd session behavior on a test device, you might receive separate feedback about the app not working properly. For completeness rejections of that kind, see our post on the Guideline 2.1 app completeness rejection.

How should you handle Apple's login on other platforms?

Many apps share one account system across iOS, Android, and the web. In that case, think ahead about how a user who signed up with Apple on iOS will reach the same account elsewhere.

Apple also offers a web flow for its login. However, you should confirm the setup details in Apple's developer documentation before you rely on it. In addition, if the user hid their email, matching accounts by email on another platform may be impossible. Therefore, link accounts by the stable user identifier Apple provides instead of by email.

Consider a sample scenario. A team that ships to both platforms from one React Native codebase may not have planned Apple's login on Android at all. Then a user who registered on iOS cannot get into their account on Android. We covered the trade-offs of a shared codebase in our React Native guide. For Android policy issues, our post on Google Play policy violation appeals is a good starting point.

How should you respond to a Guideline 4.8 rejection?

You reply to the rejection through the review conversation in App Store Connect. The goal of your reply is to help the reviewer confirm the change quickly. So skip the long defense and write short, concrete, testable information.

1. Fix the code first and upload a new build; a message alone is usually not enough.
2. State which login option you added and on which screen it appears.
3. Attach a screenshot or a short screen recording if it helps.
4. Keep the demo account details in your review notes up to date.
5. If you claim an exemption, name the exact point you rely on.

A sample reply might read: "We added a Sign in with Apple button to the login screen at the same size as the Google button. In the new build, both options appear stacked on first launch." A short note like this often works better than a long essay.

What should you write if you claim an exemption?

If your app truly qualifies for an exemption, you can reply without changing the code. However, your reply has to rest on evidence.

For example, if you build an enterprise app, explain that users can only sign in with the company's existing work account and that the app has no individual sign-up. Likewise, an app that uses an electronic ID should name the ID system it relies on. A client for a third-party service should explain that users can only reach their content through that service's account.

If App Review does not accept your explanation, you have two paths left: make the change, or appeal to the App Review Board, Apple's official appeal channel. An appeal comes with no guarantee either, because Apple makes the decision. In your appeal, then, use only verifiable facts and quote the official text of the rule.

What are the most common integration mistakes?

When teams rush the integration after a rejection, the same mistakes come up again and again. Use the list below as a checklist before you submit the new build:

• Adding the Apple button only on the sign-up screen and forgetting the login screen.
• Asking for a password or personal email after an Apple login anyway.
• Not storing the name and email that arrive with the first authorization.
• Forgetting to register sending domains for the private email relay.
• Not revoking Apple tokens in the account deletion flow.
• Changing the button title to wording the guidelines do not allow.
• Skipping the credential state check at launch.

Some of these issues fall outside Guideline 4.8. Still, they can cause a rejection under a different guideline in the same review round. Fixing them all at once therefore saves time.

How does Sign in with Apple affect privacy labels?

Adding Apple's login can change the types of data you collect. For instance, the user's name and email now arrive through this channel too. So review your App Store privacy labels against the new flow.

We explain how to fill out the labels step by step in our guide on how to prepare App Store privacy labels. In addition, asking for more data than you need at sign-up can conflict with the data collection rule, regardless of 4.8. We covered that rejection type in our post on the Guideline 5.1.1 data collection rejection.

In short, when you change the login flow, update more than the button. Update your privacy disclosures and your sign-up form as well. That way, you avoid creating a new rejection while fixing the old one.

Why is trying to work around the rule risky?

Some teams consider hiding the Google button during review or enabling social login only in certain regions. Tactics like these can count as misleading App Review, and they may lead to harsher consequences than a simple rejection.

Likewise, resubmitting the same app from another developer account is not a fix. Apple's review guidelines treat attempts to trick the review process as a serious violation. As a result, such an attempt can escalate the problem to the account level. For the rejection type tied to repeated submissions, see our post on the Guideline 4.3 spam rejection.

The safest path is to accept the purpose of the rule and offer a real equivalent option. That approach shortens the review process and gives users a more private way to log in.

How do passkeys and OAuth relate to this rule?

Most social logins rely on standards such as OAuth 2.0 and OpenID Connect behind the scenes. We explain the basics in our OAuth 2.0 guide. Apple's login uses a similar authorization flow. For 4.8, however, the technical standard matters less than whether the service delivers the three privacy features.

A passkey, on the other hand, is a way to authenticate without a password. Using passkeys in your own account system does not turn it into a third-party login service. So if you only offer your own system with passkeys, the first exemption still applies. You can learn more in our article on what a passkey is.

That said, the picture changes if you add passkeys to your own system and keep a Google button on the same screen. The social login still creates a primary account, so Guideline 4.8 applies and you need the equivalent privacy-focused option.

How do you protect existing Google users?

If your app has been live for a while, you already have users who signed up with Google or Facebook. After you add Apple's button, some of them may tap it by mistake and create a second, empty account. That leads to more support requests and complaints.

A few safeguards help. First, show a short hint on the login screen that reminds people which method they used. Then add an option in account settings to link another login method; that way, a signed-in user can connect their Apple Account to the existing profile.

However, do not merge accounts automatically just because the email addresses match. If the user shared a relay address, there is no match anyway. Even with a real address, automatic merging can create a security hole. Always link accounts with the explicit consent of a signed-in user.

How should you test the Sign in with Apple flow?

App Review may test your app on a real device with its own Apple Account. For that reason, test end to end on physical hardware, not only in the simulator. In particular, try first sign-up, sign-out and sign-in again, hidden email, and account deletion as separate scenarios.

1. Sign up with a fresh test Apple Account and confirm that the name and email reach your server.
2. Log out and log back in with the same account, then confirm no new account appears.
3. Sign up with the hidden email option and send a test message to the relay address.
4. Remove the app's Apple access in device settings and check that the app returns to the login screen.
5. Delete the account in the app and confirm that the token revocation shows up in your server logs.

If you are preparing the Android version at the same time, Google Play has its own testing rules. For example, we explain the closed testing requirement for new personal accounts in our post on the Google Play 12 testers requirement.

Before you resubmit: a final checklist

Go through this short checklist with your team before you submit. It is designed to keep you from getting the same 4.8 rejection twice:

• Every screen with a social login also shows Apple's option or an equivalent one.
• The Apple button is not smaller than the others and is visible without scrolling.
• No password or personal email is requested after sign-up, and extra data is optional.
• Delivery to a relay address was confirmed with a test account.
• The account deletion flow revokes Apple tokens.
• Privacy labels reflect the new login flow.
• Review notes include a current demo account and a short description of the change.

If you can answer yes to every item, send your reply. Then wait for the result, and if new feedback arrives, handle it the same calm way, one point at a time.

When should you get professional help?

In a simple app, adding Apple's login can take a few days. However, the work grows once multiple platforms, an existing user base, account linking, and email infrastructure come into play. Adding a new login path without breaking existing Google accounts takes careful planning.

In rejection cases like this, our team first maps the flow with you and then decides which parts really need to change. We never promise guaranteed approval, because Apple makes the call. What we can do is make sure every piece the rule requires is built properly. If you want to handle the login flow, account deletion, and your review reply together, take a look at our custom mobile app development page and get in touch.