Sign in with Appleを実装してつまずいた話

アクセシビリティ対応を進める中で、ログイン機能に他社アカウント連携（SNSログイン）を追加しようとしたところ、Appleのガイドラインで「Sign in with Apple」の実装が実質的に必須になる場合があると知り、急いで対応することになりました。

1. 「必須になる条件」を誤解していた

最初は「SNSログインを1つでも実装したら必ずSign in with Appleも必要」と単純に理解していたのですが、正確には少し条件が異なりました。

他社のログイン手段（Googleログイン等）を提供する場合、
原則としてSign in with Appleも選択肢として提供する必要がある

「アプリ内に他社アカウントでのログイン手段があるかどうか」が条件であり、独自のメール・パスワード認証だけであれば必須ではないと分かりました。自分のアプリの認証方式を改めて棚卸しし、本当に必要な対応なのかを確認してから着手しました。

実装を進める中で、Appleのログインには「メールを非公開にする」という選択肢があり、ユーザーがこれを選ぶとApple製の代理メールアドレスが渡されることを知りました。

let userIdentifier = credential.user
let email = credential.email // 初回のみ取得可能、以降はnil

さらに厄介だったのは、名前やメールアドレスは初回のログイン時にしか渡されず、2回目以降はnilになるという仕様でした。初回に受け取った情報をどこかに保存しておかないと、二度と取得できないと知らずに実装していたため、テスト中に「あれ、名前が取れない」と混乱しました。

さらに、Sign in with Appleでは、ユーザーがApple ID側の設定でアプリとの連携を解除できることも知りました。

ASAuthorizationAppleIDProvider().getCredentialState(forUserID: userIdentifier) { state, _ in
    // .revoked であれば、アプリ側もログアウト状態にする
}

アプリ側の保存情報だけを信用していると、Apple ID側で連携が切られていても、アプリ内では「ログイン済み」のままになってしまうケースがあると分かりました。起動時にこの状態を確認する処理を入れて、初めて実態に即したログイン状態を保てるようになりました。

実装が一通り終わり、シミュレーターで動作確認をしていたところ、実機と挙動が微妙に異なり、正しく動いているのか判断がつかない場面がありました。

サインイン処理自体はシミュレーターでも動きますが、実際のApple IDの挙動（特に連携解除など）を正確に確認するには実機でのテストが欠かせないと分かりました。プッシュ通知のときと同様、認証まわりの機能はシミュレーターだけで安心せず、実機確認を前提に計画しておくべきだと学びました。

「よくあるログイン機能の1つ」という認識で軽く見ていましたが、独自の仕様や制約が多く、事前の理解が欠かせない機能だったと実感しました。

本記事は生成AI（Claude）を活用して執筆・編集しています。内容は実体験に基づき、執筆者本人が確認・監修しています。