New Year Special: AI Review Toolkit $29.99 $49.99 Get it now →

iOS Submission Guide

Authentication 2026 Guide

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:

  1. Select your target → Signing & Capabilities
  2. Click "+ Capability"
  3. Search for and add "Sign in with Apple"
  4. 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

4.8

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.

4.8

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.

4.0

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.

5.1.1

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.

2.1

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

Want AI to audit your app before submission?

Get our AI Review Toolkit with prompts that catch guideline violations automatically.

Get the AI Toolkit