App Store Connect APIまわりが一段落し、次はアプリのログイン機能をパスワード不要にできないかと考え、パスキー（Passkeys）に挑戦しました。
1. アプリ側の実装だけで完結すると思っていた
最初、Xcodeでコードを書けばすぐにパスキーが使えるようになるものだと思い込んでいました。
パスキー実装に必要なもの:
Associated Domains（webcredentials）の設定
サーバー側に置くapple-app-site-associationファイル実際には自分のドメイン配下に専用ファイルを正しく配置し、アプリ側の設定と紐付けて初めて動く仕組みでした。Universal Linksの実装で経験した、ドメインとアプリを結びつける作業に近い準備が必要だと気づくまで少し時間がかかりました。
2. シミュレータで動作確認できると思っていた
実装を終えて、まずシミュレータで動作確認しようとしたところ、パスキーの作成・認証画面がうまく機能しませんでした。
シミュレータでの制約:
Face ID/Touch IDのハードウェアが必要な操作は再現が不完全パスキーの生体認証まわりは実機での確認が前提になっている部分が多く、シミュレータだけで安心してしまうと本番でつまずくと分かりました。以降は早い段階から実機での確認を組み込むようにしています。
3. 既存のパスワードログインとの共存で迷った
パスキーさえ実装すれば従来のパスワードログインは不要になると考えていたのですが、実際にはすべてのユーザーがすぐにパスキーに移行できるわけではないと気づきました。
既存のメール・パスワードでのログインを残しつつ、パスキーを「より簡単な選択肢」として並行提供する設計に変更しました。片方だけに寄せてしまうと、パスキーに対応していない環境のユーザーを締め出してしまうリスクがあると実感しました。
4. エラーメッセージが抽象的で原因特定に時間がかかった
動作確認中にパスキーの作成が失敗するケースがあり、返ってくるエラーが抽象的で原因がなかなか分かりませんでした。
発生したエラー:
リクエストが完了できませんでした（原因の詳細なし）調べてみると、Associated Domainsの設定ファイルの内容とアプリのBundle IDが一致していないことが原因でした。パスキー関連のエラーは詳細な理由が示されないことが多いため、まず設定ファイルとアプリ側の紐付けを一つずつ確認するのが結局は近道でした。
まとめ
- パスキーの実装はアプリ側のコードだけでなく、ドメイン側のファイル設置とセットで初めて動く
- 生体認証がからむ挙動はシミュレータでは再現が不完全な部分があり、早めに実機で確認する
- 既存のパスワードログインをすぐに置き換えるのではなく、選択肢として並行提供する設計にする
- エラーメッセージが抽象的な場合、まずドメインとアプリの紐付け設定を疑って確認する
パスワードを覚えなくていい体験は魅力的でしたが、裏側の設定を正しく揃えるまでの準備に一手間かかる実装でした。
次は、TipKitでアプリ内のヒント表示を実装してみて分かったことをまとめます。
本記事は生成AI（Claude）を活用して執筆・編集しています。内容は実体験に基づき、執筆者本人が確認・監修しています。
コメント