Skip to main content

​
Automatic Passkey Creation in Native Apps (Conditional Create)

When a user signs in to your app with a password supplied by their credential manager, the OS can create a passkey for that account without showing any UI at all. There is no sheet, no biometric prompt and no interruption to your app. The credential manager notifies the user afterwards. This is the same conditional create mechanism as the web automatic upgrade, available to native apps on both platforms. It is the highest-yield creation flow available, because it costs the user nothing.
Support (August 2026): iOS 18+, iPadOS 18+, macOS 15+ and visionOS 2+ via ASAuthorizationPlatformPublicKeyCredentialProvider. Android relying parties use androidx.credentials 1.6.0 (stable since 8 April 2026); Google Password Manager support requires Google Play services 25.13 or newer. On both platforms, the user’s preferred credential manager can participate when it supports conditional registration. Android providers receive these requests through CredentialProviderEventsService, whose provider-facing library is separately versioned and may not yet be implemented by every provider.
1

User signs in with an autofilled password

  • The user’s credential manager fills a saved username and password for your app, and the sign-in succeeds.
  • This is the hard precondition. Sign-ins that do not use a stored password (magic links, SMS or email OTP, and federated or SSO sign-in) do not qualify.
2

Your app requests a conditional registration

  • Immediately after the successful password sign-in, the app issues a registration request marked as conditional.
  • On Apple platforms, request ASAuthorizationPlatformPublicKeyCredentialRegistrationRequest.RequestStyle.conditional.
  • On Android, set isConditional = true on CreatePublicKeyCredentialRequest and send it through CredentialManager.createCredential().
3

The credential manager decides, silently

  • The provider checks its own conditions: a matching password was filled recently, the device is set up for passkeys, and no passkey exists yet for this account.
  • If an eligibility condition fails, the request returns an expected no-op error and no UI is shown to the user. Nothing went wrong; a passkey simply was not created this time.
4

Passkey created, user informed by the system

  • On success the passkey is created with no prompt and no user interaction.
  • The credential manager, not your app, notifies the user that a passkey now exists. Do not add your own confirmation screen on top of it.

​
What your server must tolerate

The registration response carries UP and UV as false. No user interaction takes place, so there is no user presence or user verification to assert. A registration verifier configured to reject UV=0 will fail every automatic upgrade. This is the most common integration bug on this flow, and it fails silently from the user’s point of view.

​
Platform differences worth planning for

On Android, include every server-known credential ID in excludeCredentials. This prevents the selected provider from creating a duplicate of a credential it already holds, and a duplicate surfaces through InvalidStateError. On Apple platforms the native registration request has no excludedCredentials property, so duplicate avoidance is delegated entirely to the credential manager. Do not suppress the conditional request merely because your server knows that the account has another passkey: it may live in a different provider or may not be available on this device. Issue the request after an eligible password login and let the credential manager determine whether it already holds a matching passkey.
Credential Manager forwards a conditional create request to the user’s preferred provider when the provider supports the flow. Google Password Manager requires Google Play services 25.13 or newer; older versions may fail with CreateCredentialUnsupportedException. Third-party providers can receive conditional requests through CredentialProviderEventsService, but support is provider-dependent, so keep the explicit creation fallback described below.
Credential managers implement performWithoutUserInteractionIfPossible(passkeyRegistration:) and declare SupportsConditionalPasskeyRegistration in their extension capabilities. A provider is not permitted to show UI while fulfilling the request.
Do not show a user-facing error when conditional creation is simply ineligible, but do not swallow every exception. On Android, handle CreateCredentialNoCreateOptionException as an expected no-op and inspect CreatePublicKeyCredentialDomException.domError for expected InvalidStateError, NotAllowedError and AbortError outcomes. Record unsupported, provider-configuration, malformed-request and unexpected failures in telemetry. On Apple platforms, suppress UI for eligibility or cancellation outcomes while logging association, entitlement, request-construction and unexpected failures. Retry expected no-op outcomes on the user’s next password sign-in.
Google Password Manager offers a setting that disables automatic passkey creation and syncs it across the user’s devices. Plan for adoption that never reaches 100%, and keep an explicit creation path such as the post-login nudge available.
Because the passkey is created without the user choosing to create it, keep passkey management easy to find. A user who is surprised by the system notification should be able to see and remove the credential immediately.

​
Further reading