Passkey Creation UI With Biometrics, Done Right

Passkeys replace passwords with a Face ID or Touch ID prompt, and because there is no shared secret to phish, they are far safer. The short answer: build a clear passkey creation flow from a free VP0 design, explain the benefit in one line, trigger Apple’s system passkey sheet, and confirm success, then wire it with Authentication Services. Google has reported that signing in with a passkey is roughly 2x faster than a password while being phishing-resistant, so the experience is both safer and quicker.

What the passkey UI must communicate

Passkeys are new to many users, so the interface has to build confidence fast. Lead with the benefit in plain language: “Sign in with Face ID, no password to remember.” When the user opts in, the system presents the native passkey sheet; your screens are the before (a simple value prop and a single button) and the after (a clear “You are all set” confirmation). Avoid jargon like “WebAuthn” or “FIDO2” in the UI. Apple’s Human Interface Guidelines and its passkeys developer guidance both stress letting the system handle the sensitive moment while you keep the surrounding copy reassuring.

Build it from a free design

VP0 is a free iOS design library for AI builders. Pick a sign-in, onboarding, or confirmation design, copy its link, and have Cursor or Claude Code rebuild it in SwiftUI. The critical point: you do not build the biometric check or store any fingerprint or face data yourself. Face ID and Touch ID are handled by the Secure Enclave, and you create and use passkeys through Apple’s Authentication Services with ASAuthorizationPlatformPublicKeyCredentialProvider. Your job is the value prop, the button that kicks off the system sheet, and graceful handling of success, cancel, and error. Always provide a fallback sign-in and a recovery path so a lost device never means a locked-out user. For the screen this often lives in, see iOS onboarding screen design that actually converts, and for a sensitive verification cousin, see fintech KYC verification screen UI.

Passkey flow states

Design every state, not just the happy path.

State	What the user sees	Note
Value prop	One-line benefit, single button	No jargon
System sheet	Native passkey or Face ID prompt	Apple handles this
Success	Clear confirmation	Reassure, move on
Cancel	Return without penalty	Offer to try later
Fallback	Alternate sign-in path	Never strand the user

Common mistakes

The first mistake is trying to build your own biometric capture or store face or fingerprint data; you must not, and you do not need to. The second is drowning the user in security jargon instead of a plain benefit. The third is offering no fallback, so a user without their device is locked out. The fourth is skipping recovery, leaving no way back after a lost device. The fifth is hiding what a passkey is; one reassuring sentence about “no password to leak” does more for adoption than a wall of text.

A worked example

Say you are adding passwordless sign-in. Your VP0-built screen shows “Set up Face ID sign-in, no password needed” and one button. Tapping it triggers the system passkey sheet via Authentication Services; on success, a clean “You are set, next time just look at your phone” confirmation appears. You keep an email or Sign in with Apple fallback and a documented recovery flow. Nothing biometric is ever stored by your app. For the standards-based identity option that pairs naturally with this, see Apple Sign-In UI guidelines Figma.

Key takeaways

• Passkeys swap passwords for Face ID or Touch ID and are phishing-resistant.
• Build the creation flow from a free VP0 design: benefit line, button, confirmation.
• Never store biometrics; the Secure Enclave and Authentication Services handle that.
• Always provide a fallback sign-in and a clear recovery path.
• Keep the copy plain; one reassuring sentence beats security jargon.

Frequently asked questions

What is a passkey and why use it? A passkey lets users sign in with Face ID or Touch ID instead of a password. Because there is no shared secret, it is resistant to phishing and is faster for the user.

How do I build a passkey creation flow on iOS? Design the value prop, button, and confirmation from a free VP0 design, then trigger the system sheet with Apple’s Authentication Services (platform passkeys). Do not build or store biometrics yourself.

Do I store the user’s Face ID or fingerprint? No. Biometrics never leave the Secure Enclave, and your app never sees or stores them. You only create and use passkeys via Apple’s APIs.

What if the user loses their device? Provide a fallback sign-in (such as email or Sign in with Apple) and a documented recovery path so a lost device never locks the user out permanently.