Fix a Sign in with Apple App Review rejection

Identify whether the requirement is triggered

Apple's Sign in with Apple materials and guideline text should be read against the actual sign-in choices in the app. Email-and-password only, enterprise-only, or a single first-party account system may present a different case from consumer social login buttons.

Make a login inventory: Google, Facebook, WeChat, Line, Microsoft, enterprise SSO, carrier login, email magic link, password, anonymous guest, and device account. For each option, record where it appears and whether it creates or authenticates a general user account.

Build parity into placement and account behavior

• Place Sign in with Apple where comparable third-party sign-in options appear, not behind an obscure secondary route.
• Support first-time account creation and returning-user authentication from the submitted build.
• Handle private relay email addresses without forcing the user to reveal a different email.
• Make account linking, duplicate-account resolution, logout, and reauthentication deterministic.
• Apply the same access level after successful Sign in with Apple unless a documented role rule applies.

Connect Sign in with Apple to deletion and token revocation

Sign in with Apple does not end at authentication. Apple's technical note on account deletion describes token revocation work for accounts using Sign in with Apple. If the app supports account creation and deletion, the reviewer may need to see that the identity lifecycle is coherent.

Document how the backend stores Apple user identifiers, handles email relay changes, revokes tokens on deletion, and treats a later sign-up by the same person. AppReviewReady interpretation: keep this in the account-deletion test plan because login and privacy failures often appear together.

Run a clean-device login acceptance test

1. Install the release candidate on a device that is not carrying an internal session.
2. Create a new account with Sign in with Apple using both shared and private relay email choices when applicable.
3. Log out, reinstall or clear state, and sign back in to the same account.
4. Exercise the primary gated feature, purchase or subscription entitlement if relevant, and account settings.
5. Delete the account from the in-app flow and verify token revocation or the documented backend path.

Respond with parity evidence

If the previous rejection was caused by a hidden or broken Apple button, name the exact fix. If the team believes the requirement does not apply, explain the login model with screenshots or steps, but avoid arguing from a category label alone.

Sign in with Apple fix:
Triggering sign-in options: [list]
Apple option location: [screen and control]
Parity behavior: [account creation, returning login, relay email support]
Deletion/token handling: [implemented path]
Reviewer steps: 1) [tap] 2) [choose Apple] 3) [expected account state]
Build or metadata changed: [identify]