Human Interface GuidelinesのAuthenticationのページが更新されたとのことなので和訳しました。
認証
認証は、パーソナライズされた体験の提供、追加機能の提供、コンテンツの購入、データの同期などの価値あるものとの引き換えにのみ求めるようにしましょう。もしあなたのアプリで認証が必要なら、アプリの楽しみの妨げにならないよう、サインインのプロセスをすばやく、簡単に、そして邪魔にならないようにしましょう。
全てのサインアップ、サインインプロセスでPassword AutoFillを使いましょう
パスワードとセキュリティコードが自動で生成、入力されるこの機能により、ユーザは認証画面で過ごす時間を減らすことができます。全てのアプリはこの機能をサポートすべきです。開発者向けのガイダンスはSupporting Password AutoFillをご覧ください。
サインインはできるだけ遅らせよう
ユーザは、何かをする前にサインインを強制されるとアプリを使うのをやめてしまうことがしばしばあります。なのでサインインさせる前にアプリに恋をする機会を与えましょう。ショッピングアプリの場合、商品の閲覧はアプリ起動直後にできるようにし、商品を購入する段階になってからサインインを要求しましょう。メディア閲覧アプリの場合、サインインをする前にコンテンツを探したり閲覧したりできるようにしましょう。
認証することのメリット、サインアップの方法を説明しましょう
もしあなたのアプリで認証が必要なら、ログイン画面でわかりやすく、手短にその理由とメリットを説明しましょう。また、あなたのアプリを使用している全てのユーザが最初からアカウントを持っているわけではないということに注意してください。どのように作るのか、アプリ内でどうサインアップするのか説明するようにしましょう。
適切なキーボードを表示し、データ入力を最小限に抑えましょう
例えばメールアドレスを入力してもらう場合、データ入力がショートカットできるものと一緒にメール入力用キーボードを表示しましょう。関連ガイダンスとしてKeyboardsもご覧ください。利用可能なキーボードリストはUITextInputTraitsのUIKeyboardTypeを参照してください。
パスコードという用語を使わないでください
パスコードはiOS端末のロックを解除したり、生体認証が無効で別途Apple Payの認証が必要な場合に使うものです。
Apple PayのデザインガイダンスはApple Payを参照してください。
Face ID と Touch ID
可能な限り生体認証をサポートするようにしましょう
Face ID、Touch IDは信頼できる、安全で親しみやすい認証方法です。ユーザが生体認証を有効にしている場合は、きっとユーザはその使い方を理解し利便性を高く評価しているので、可能な限り生体認証を使いたいと思うでしょう。一方生体認証を無効にする人もいるので、この場合のシナリオにも対応できるよう準備することを忘れないでください。
認証方法の提示は1つだけにしましょう
認証の選択肢が他にない状況だと、人は最も直感的になれます。なのでFace IDのように一つの選択肢だけ与えるようにしましょう。最初の認証方法で失敗した時のみ、ユーザ名とパスワードの入力のような代替手段を提示するようにしましょう。
ユーザがアクションした時のみ認証を開始しましょう
ボタンをタップするなどの明示的な操作は、ユーザが認証したいと思っていることを表します。Face IDの場合は、ユーザがカメラに顔を向けた時にその可能性が高くなります。
常に認証方法を明確にしましょう
例えばFace IDを使用してログインするためのボタンは、"ログイン"ではなく"Face IDでログイン"というタイトルにすべきです。
認証方法への言及は正確にしましょう
Face IDをサポートしている端末でTouch IDについて触れないでください。逆に、Touch IDをサポートしている端末ではFace IDについて触れないでください。デバイスの特性を確認し、適切な用語を使用してください。開発者向けのガイダンスはLABiometryTypeを参照してください。
特に何もなければアプリ内で生体認証を有効にする設定を使用しないようにしましょう
生体認証がシステムレベルで有効になっている場合のみ、ユーザがそれを使いたいと思っているとみなしましょう。もしアプリで固有の設定ができる実装をしてしまうと、システム全体では生体認証を無効にしているのに、あなたのアプリでは有効になっているような状態ができてしまう可能性があります。
システムが提供している認証機能と同じアイコンは使わないでください
システムが使用しているTouch ID（親指の指紋）アイコン、Face IDアイコンのようなものを見た場合、ユーザは認証しなければいけないと思ってしまいます。このような認証アイコンを使ってしまうと、矛盾が生じたり、混乱を引き起こしたりしてしまいます。特にそのアイコンに色が付いていたり、大きいサイズで表示されていたり、文脈から外れて表示されている場合はなおさらです。
開発者向けガイダンスはLocal Authenticationをご覧ください。