Sign in with Apple: Complete Implementation Guide
Sign in with Apple (SIWA) is required for most apps with third-party login. This guide covers when you need it, how to implement it correctly, and how to avoid the most common rejection reasons.
The Simple Rule
If your app has any third-party login (Google, Facebook, Twitter, etc.), you must also offer Sign in with Apple. The only exceptions are apps that exclusively use your own authentication system or certain enterprise/education apps.
Why Apple Requires This
Apple introduced Sign in with Apple in 2019 and made it mandatory in 2020. The rationale is straightforward: if you let users sign in with their Google or Facebook accounts, Apple wants users to have a privacy-focused alternative that:
Privacy First
Users can hide their real email address with Apple's private relay
No Tracking
Apple doesn't track users across apps like social login providers
Seamless UX
One-tap sign in with Face ID/Touch ID on Apple devices
When Sign in with Apple Is Required
Guideline 4.8 specifies exactly when you must implement Sign in with Apple. Here's the definitive breakdown:
| Your App's Login Options | SIWA Required? |
|---|---|
| Google Sign-In | Yes, Required |
| Facebook Login | Yes, Required |
| Twitter/X Sign-In | Yes, Required |
| Any other social login (GitHub, LinkedIn, etc.) | Yes, Required |
| Email + Password only (your own system) | Not Required |
| Phone number authentication only | Not Required |
| No authentication (app works without login) | Not Required |
| Enterprise apps (MDM distributed) | Exempt |
| Education apps using school credentials | Exempt |
| Government/civic apps with required credentials | Exempt |
⚠️ Common Misconception
"I'll just remove Google Sign-In to avoid implementing SIWA." This often backfires—users expect social login, and removing it can hurt engagement. SIWA is straightforward to implement and most users appreciate having it as an option.
Basic Implementation
Sign in with Apple uses the AuthenticationServices framework. Here's a complete implementation:
1 Enable the Capability
In Xcode, add the Sign in with Apple capability:
- Select your target → Signing & Capabilities
- Click "+ Capability"
- Search for and add "Sign in with Apple"
- This automatically configures your entitlements and provisioning profile
2 Create the Authorization Request
SwiftUI implementation:
import AuthenticationServices
struct SignInView: View {
var body: some View {
SignInWithAppleButton(
onRequest: { request in
request.requestedScopes = [.fullName, .email]
},
onCompletion: { result in
switch result {
case .success(let auth):
handleAuthorization(auth)
case .failure(let error):
handleError(error)
}
}
)
.signInWithAppleButtonStyle(.black) // or .white, .whiteOutline
.frame(height: 50)
}
}
3 Handle the Authorization Response
func handleAuthorization(_ authorization: ASAuthorization) {
guard let credential = authorization.credential
as? ASAuthorizationAppleIDCredential else {
return
}
// User identifier - ALWAYS available, never changes
let userIdentifier = credential.user
// Email - only provided on FIRST sign-in
let email = credential.email
// Name - only provided on FIRST sign-in
let fullName = credential.fullName
// Identity token for server verification
if let identityToken = credential.identityToken,
let tokenString = String(data: identityToken, encoding: .utf8) {
// Send to your server for verification
authenticateWithServer(
userID: userIdentifier,
identityToken: tokenString,
email: email,
name: fullName
)
}
}
4 Check Credential State on App Launch
Verify the user's credential is still valid:
func checkCredentialState() {
let provider = ASAuthorizationAppleIDProvider()
provider.getCredentialState(forUserID: savedUserID) { state, error in
switch state {
case .authorized:
// User is still authorized
break
case .revoked:
// User revoked - sign them out
signOut()
case .notFound:
// User not found - credential invalid
signOut()
case .transferred:
// User transferred to a different Apple ID
handleTransfer()
@unknown default:
break
}
}
}
Handling User Data Correctly
The biggest source of SIWA bugs is misunderstanding when user data is provided. Here's the critical rule:
⚠️ Critical: Email and Name Are Only Sent Once
Apple only sends the user's email and name on the very first sign-in. If you fail to capture and store this data, you will never receive it again for that user.
On subsequent sign-ins, only the userIdentifier is provided.
First Sign-In
Data you receive:
- ✓ userIdentifier (always)
- ✓ email (if requested & user consents)
- ✓ fullName (if requested & user consents)
- ✓ identityToken (for verification)
Subsequent Sign-Ins
Data you receive:
- ✓ userIdentifier (always)
- ✗ email (never re-sent)
- ✗ fullName (never re-sent)
- ✓ identityToken (for verification)
💡 Best Practice: Persist Immediately
When you receive the authorization callback, immediately send the email and name to your server before doing anything else. Don't wait for a "successful" response from other parts of your flow—if any step fails, you'll lose that data forever.
Handling Private Email Relay
When users choose "Hide My Email," Apple provides a private relay address like xyz123@privaterelay.appleid.com. You must:
- Configure your domain in Apple Developer to send emails to relay addresses
- Treat relay addresses as valid email addresses (they forward to real accounts)
- Never assume you'll have a "real" email address—plan for relay addresses
Account Deletion Requirement
As of June 2022, apps that support account creation must also support account deletion. This applies to all authentication methods, including Sign in with Apple.
⚠️ Guideline 5.1.1(v) - Account Deletion
"Apps that support account creation must also offer account deletion. This functionality must be easy to find, must not require contacting support, and must delete the account along with associated data."
What You Must Implement
- In-app deletion option - Must be accessible from Settings/Account, not buried or requiring support contact
- Actual data deletion - Delete user data from your servers (or schedule for deletion within 30 days)
- Revoke Apple tokens - You must revoke the Sign in with Apple refresh token
Revoking Apple Tokens
When a user deletes their account, call Apple's revocation endpoint:
// Server-side token revocation
POST https://appleid.apple.com/auth/revoke
Content-Type: application/x-www-form-urlencoded
client_id=<your_app_bundle_id>
&client_secret=<your_client_secret_jwt>
&token=<refresh_token_or_access_token>
&token_type_hint=refresh_token
This tells Apple the user has deleted their account, and they'll see a "stopped using" status in their Apple ID settings.
🕐 Delayed Deletion Is Allowed
You can implement a "cooling off" period (up to 30 days) where the account is scheduled for deletion but can be recovered. Just make sure users understand their data will be deleted and when.
Common Sign in with Apple Rejections
Sign in with Apple Not Offered
"Your app uses third-party login services but doesn't offer Sign in with Apple."
Fix: Add Sign in with Apple as an equal option alongside other social login buttons.
Sign in with Apple Not Equally Prominent
"Sign in with Apple must be displayed with equal prominence to other login options."
Fix: Make the SIWA button the same size and visual weight as other login buttons. Don't hide it at the bottom or make it smaller.
Button Style Not Compliant
"Your Sign in with Apple button doesn't follow Apple's Human Interface Guidelines."
Fix: Use the system-provided SignInWithAppleButton or follow Apple's exact button design guidelines. Don't create custom buttons.
No Account Deletion
"Your app supports account creation but doesn't provide a way for users to delete their account."
Fix: Add a "Delete Account" option in Settings/Account. Implement actual data deletion and Apple token revocation.
Sign in with Apple Not Functional
"We were unable to sign in using Sign in with Apple."
Fix: Test thoroughly on a fresh Apple ID. Handle all credential states. Check that your server correctly verifies Apple's identity token.
Sign in with Apple Checklist
Implementation
- Sign in with Apple capability enabled in Xcode
- Using system SignInWithAppleButton component
- Requesting email and name scopes
- Persisting email/name on first sign-in
- Checking credential state on app launch
Button Placement
- Equal prominence with other login options
- Same size as other social login buttons
- Not hidden or below the fold
- Using approved button style (black/white/outline)
Server-Side
- Verifying Apple identity tokens
- Storing userIdentifier for user lookup
- Handling private relay email addresses
- Domain configured for email relay
Account Deletion
- Delete account option in Settings
- Actual data deletion implemented
- Apple token revocation on deletion
- Clear confirmation before deletion
Frequently Asked Questions
Can I remove other social logins and just use email/password?
Yes. If your app only uses email/password authentication (your own system), SIWA is not required. However, removing social login options may reduce sign-up conversion rates.
The user used "Hide My Email" - how do I contact them?
Email the private relay address. Apple forwards it to their real email. You must configure your sending domain in Apple Developer Portal under Services → Sign in with Apple for Email Communication.
User signed up with SIWA but wants to switch to email/password?
You can implement account linking. Ask for their email (or use the one from SIWA if available), let them set a password, and store both auth methods for the same account. They can then use either to sign in.
I missed capturing the email on first sign-in. Can I get it again?
No. Apple only sends email/name once. The user would need to go to Settings → Apple ID → Password & Security → Apps Using Your Apple ID, remove your app, then sign in again. You can't programmatically trigger this.
Does Sign in with Apple work on web/Android?
Yes. Apple provides Sign in with Apple JS for web and REST APIs for any platform. If your iOS app uses SIWA, users should be able to access their account on other platforms too.
Related Guides
Get Your Authentication Right the First Time
Our AI Review Toolkit includes authentication-specific prompts that verify your Sign in with Apple implementation, account deletion flow, and privacy compliance before you submit.
Get the AI Toolkit