Native App Passkey Errors: Ultimate Overview (2026)

When deploying native apps at large scale with passkeys, difficult problems start appearing that cannot be anticipated. Why is it so difficult to deploy passkeys in native apps?

Want to find out how many people use passkeys?

View Adoption Data

The most important matter: code cannot be changed once deployed. One version will often stay available for a long period. The second matter: diagnosing problems is difficult - you can't easily inspect what's happening inside the user's device. The third matter: the environment is constantly changing and extremely heterogeneous - your app runs across dozens of OS versions, hundreds of device models, multiple authenticator configurations and varying network conditions, all shifting independently while your code stays frozen.

What this article covers vs related articles:

• For platform-specific error code references: see Apple Passkey Error Codes (iOS) and GPS Passkey Error Codes (Android)
• For web browser errors (DOMExceptions like NotAllowedError and AbortError): see WebAuthn Errors in Production
• This article: the operational layer - what breaks in native passkey deployments, how to measure it and when to act

In this article we answer the following questions:

• What can break - We take apart what can break in a native environment and what it encompasses
• How to measure - How should you measure native implementation of passkeys?
• Mitigation - What measures should you take to protect your native application?

Your implementation architecture determines which error surface you're dealing with. There are three primary approaches, each producing a different class of errors. For full implementation guidance, see Native App Passkeys: Native vs. WebView Implementation.

Many production apps combine approaches: attempt native login first with preferImmediatelyAvailableCredentials for instant authentication, then fall back to System WebView when no credential is available. This combination is where the error classification in this article becomes most relevant - you need to handle both native error codes and web DOMExceptions in the same flow.

The following discussion focuses on native implementation errors for Android and iOS. This analysis applies whenever you implement either operation:

• WebAuthn Get - Login with a credential
• WebAuthn Create - Create a new credential

Understanding errors in native apps requires tracking the full environment context. Unlike web browsers where you control the update cycle and users run mostly recent versions, native apps face a dramatically more complex matrix. Your immutable code runs across a constantly shifting landscape of OS versions, hardware capabilities and authenticator states.

The environment for a native passkey implementation consists of eight independent dimensions that all vary simultaneously:

The environmental complexity described above creates dramatically different outcomes on Android vs iOS. Android's extreme heterogeneity makes it 3-5x more susceptible to passkey implementation failures compared to iOS in production environments.

When measuring abort rates across native passkey implementations, the distribution consistently reveals the Android diversity problem across virtually every deployment we have data or reports on:

Key insight: The worst iOS device performs better than the median Android device. iOS maintains consistency across its ecosystem because Apple controls both hardware and software. Android's open ecosystem creates massive variance.

Android error rates cluster strongly by manufacturer, revealing how deeply customization affects reliability:

For comparison, iOS devices cluster tightly around 2-5% regardless of model, with outliers only appearing on very old hardware (iPhone 8/X era) running outdated iOS versions.

Device protection type amplifies the Android fragmentation problem:

Why this matters: On Android budget devices, PIN/code authentication can push abort rates from 30% to 60%+. The same operation on iOS might go from 3% to 6% - still usable.

The root cause is architectural:

iOS: Apple controls the entire ASAuthorization stack. iCloud Keychain integration is identical on iPhone 16 and iPhone 17 Pro. Updates are synchronized. Biometric hardware (Face ID, Touch ID) is standardized per generation.

Android: Manufacturers customize everything:

• Samsung's biometric stack differs from Google's
• Some manufacturers (OnePlus, Xiaomi, Oppo) ship heavily modified Android builds
• Google Play Services version variance affects Credential Manager availability
• Budget device manufacturers optimize for cost, not reliability
• Third-party provider support is optional - manufacturers can disable it entirely

This means an error on a Samsung Galaxy A15 running Android 15 tells you nothing about what will happen on a Pixel 9 running the same Android version. The codepaths are different.

When you see high abort rates:

On iOS:

• Likely a code bug (your implementation is broken)
• Or user behavior pattern (users actually canceling - ASAuthorizationErrorCanceled code 1001)
• Or environmental issue (iCloud Keychain disabled/not signed in - surfaces as ASAuthorizationErrorFailed code 1004 wrapping an internal "Cannot create a passkey. iCloud Keychain is off." error, or the new ASAuthorizationError.deviceNotConfiguredForPasskeyCreation code 1010 on iOS 26+)

On Android:

• Could be code bug
• Could be user behavior
• Could be manufacturer customization breaking Credential Manager
• Could be budget device with broken biometric hardware
• Could be OS version too old for stable Credential Manager
• Could be device manufacturer disabled third-party provider support
• Could be Google Play Services version incompatibility

Bottom line: Don't use the same error rate thresholds for Android and iOS. A 5% abort rate on iOS might indicate a problem. The same 5% on Android flagship devices is excellent. On Android budget devices, anything under 30% is acceptable. For testing these device-specific behaviors systematically, see Testing Passkey Flows in Native iOS & Android Apps.

Authentication Analytics Whitepaper:
Track passkey adoption & impact on revenue.

Get Whitepaper

If you want to diagnose passkey issues in native apps, you need to separate where the failure happened from how it was classified later.

The following diagram shows the full lifecycle of a native passkey registration (create) operation. The flow applies to both Android (Credential Manager → TEE) and iOS (ASAuthorizationController → Secure Enclave). Each numbered step represents a boundary where failures can occur - from the app through the OS framework, down to secure hardware and back to the server:

flowchart LR

  subgraph CLIENT["Client Device"]
    direction TB

    subgraph APP_SPACE["App Space (User Space)"]
      U["1. User starts registration"]
      APP["2. App + Passkey SDK"]
      PAYLOAD["7. Build registration payload"]
      E1["11. Expected error (user cancelled)"]
      E2["12. Unexpected error (pre/during auth)"]
      E3["13. Unexpected error (post-auth)"]
      U --> APP
    end

    subgraph FRAMEWORK["OS Framework Services"]
      CM["4. Credential Manager / ASAuthorization"]
      BIO["5. Biometric or Device Credential UI"]
    end

    subgraph KSPACE["OS Kernel Space"]
      KERN["5b. Kernel key operation path"]
    end

    subgraph HWSEC["Secure Hardware Boundary"]
      TEE["5c. TEE / Secure Enclave"]
    end

    CRASH{{"14. App Crash"}}
  end

  subgraph SERVER["Passkey Server"]
    SS["3. Start returns attestation options"]
    SF["9. Finish - verify and store passkey"]
  end

  APP -- "2b. HTTPS request start" --> SS
  SS -- "3b. Attestation options" --> APP

  APP --> CM
  CM --> BIO
  BIO --> KERN
  KERN --> TEE
  TEE --> KERN
  KERN --> CM
  CM --> APP

  APP --> PAYLOAD
  PAYLOAD -- "8. HTTPS request finish" --> SF
  SF -- "10. Success response" --> APP

  SS -. "3c. Failed to generate options" .-> E2
  CM -. "11a. User cancelled" .-> E1
  CM -. "11b. Credential Manager error" .-> E2
  CM -. "12a. Provider or API failure" .-> E2
  KERN -. "12b. Key operation failure" .-> E2
  SF -. "13a. Verification or storage failed" .-> E3
  CM -. "14a. Unhandled exception" .-> CRASH

  style E2 fill:#4a1a1a,stroke:#ff6b6b,stroke-width:2px,color:#ff6b6b
  style E3 fill:#4a1a1a,stroke:#ff6b6b,stroke-width:2px,color:#ff6b6b
  style CRASH fill:#4a1a1a,stroke:#ff6b6b,stroke-width:2px,color:#ff6b6b

  linkStyle 13 stroke:#ff6b6b,stroke-width:2px
  linkStyle 15 stroke:#ff6b6b,stroke-width:2px
  linkStyle 16 stroke:#ff6b6b,stroke-width:2px
  linkStyle 17 stroke:#ff6b6b,stroke-width:2px
  linkStyle 18 stroke:#ff6b6b,stroke-width:2px
  linkStyle 19 stroke:#ff6b6b,stroke-width:2px

In practice, native WebAuthn failures happen in five stages:

On both platforms, the authenticator invocation stage is where native apps have a decisive diagnostic advantage over web browsers. Both Apple and Google compress dozens of specific internal error codes into a small set of public error types before they reach your app - and browsers lose even more detail on top of that. Native apps that log the raw platform errors can distinguish root causes that browsers collapse into generic NotAllowedError.

On Android, GPS generates 50+ internal error codes that are compressed into 12 WebAuthn types. Native apps can parse the [50xxx] prefixed error messages to identify specific failures like Folsom sync key decryption (error 50162) that Chrome reports as generic NOT_ALLOWED_ERROR. For the complete error code reference, architecture diagrams and androidx.credentials error handling guide, see GPS Passkey Error Codes: the complete Reference.

On iOS, Apple compresses ~22 internal error codes into 11 public ASAuthorizationError codes. Native apps receive dedicated codes for common failures (1001 for user cancel, 1005 for no credentials, 1010 for device not configured) that Safari collapses into generic DOMExceptions. For the complete error code reference, translation mapping and Swift error handling guide, see Apple Passkey Error Codes: the complete Reference.

Beyond these stages, two behavioral patterns are critical to detect:

Authentication loop detection: When the authenticator invocation fails and error handling is incorrect, the app can enter a retry loop - repeatedly invoking the authenticator, crashing or failing each time. This is especially dangerous in native apps because the user has no way to break out except force-closing the app. At Corbado, we detect these loops server-side by tracking repeated failed attempts from the same session within a short time window. A loop pattern (3+ failed attempts within a few minutes) is a strong signal that the app's error handling is broken on that specific device/OS combination.

Authentication avoided by device change: When a user consistently authenticates on one device but suddenly switches to another (e.g. moving from native app to web browser, or from one phone to another), this often signals a problem. The user is actively working around a broken passkey flow on their primary device. Tracking device-change patterns after failed authentication attempts reveals which device/OS/version combinations are silently pushing users away from passkeys - even when no error was reported.

Want to experiment with passkey flows? Try our Passkeys Debugger.

Try for Free

Without dedicated tooling, teams typically discover native passkey problems reactively - a support ticket spike, a sudden drop in login conversion or a vague "passkeys don't work on my phone" report. By the time you investigate, the damage is done: users have churned, fallback flows have been triggered silently and the root cause is buried in aggregate metrics.

Corbado's passkey analytics platform continuously monitors device-level passkey health across your entire user base - both for passkey creation and passkey login. Instead of waiting for complaints, you see which device models are failing, how error rates trend over time and whether a new OS update or GPS version introduced regressions. Effective native passkey analytics needs two layers working together: outcomes that tell you "how bad is the user impact?" and events that tell you "what is technically failing?" - the sections below walk through both. For the full analytics framework, see Passkey Analytics and the Authentication Analytics Playbook. The screenshots below show sample data from a demo environment for illustration purposes.

The first layer of monitoring is the device health view for passkey creation. This surfaces the "top offenders" - device models with the highest abort rates during passkey registration - ranked by error percentage and with per-device event counts for statistical confidence.

On iOS, the dashboard immediately reveals patterns that would take weeks to discover manually: older devices stuck on iOS 16 (iPhone 8 Plus, iPhone X, iPhone 8) cluster at the top with 20%+ abort rates, while modern devices on iOS 18+ sit around 10-12%. The Block button lets you suppress passkey creation prompts for specific device cohorts where the failure rate is unacceptable - Passkey Intelligence then skips passkey creation entirely on those devices instead of leading users into a dead end.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Device health tells you where things break. The error classification view tells you what is breaking - grouping individual errors into named patterns with counts, rates and trend indicators.

This is where you move from "Android has a higher abort rate" to actionable engineering work. The trend percentages are the key signal, here just some exemplary sample data in production there are over 100 classifications: While the top pattern (authenticator timeout) is declining at -9%, the iOS native unknown errors are growing at +25% and Android native at +37%. A Bitwarden Chrome extension bug has spiked +205% - likely triggered by a recent extension update. The same drill-down workflow applies to any pattern in the list - the native iOS and Android errors visible here work exactly the same way. We follow the Bitwarden spike below because it had the largest trend change, but investigating a native ASAuthorizationError or Credential Manager failure uses the same path. Clicking into any pattern opens a detailed view where you can analyze how the error developed over time, see it in context of total login volume and inspect individual error samples:

The error trend chart shows the Bitwarden extension bug spiking in November before declining again - correlated against total login volume (dashed line) to distinguish real regressions from traffic fluctuations. The samples table at the bottom surfaces the exact event type, error message, OS and browser for each occurrence, giving engineers everything they need to reproduce and fix the issue.

From any error sample you can open the full process detail view - the individual authentication process with its complete context, subprocesses and event timeline.

This example shows a user on Windows 10 with Chrome 145. The client capabilities section at the top confirms the browser supports ConditionalCreate - a WebAuthn feature that silently creates a passkey during a password login, upgrading the user without prompts. The process contains four subprocesses: two login attempts and two append (passkey creation) attempts. The second append failed with two errors - both flagged as append-error-unexpected. Drilling into the events reveals one is a clientPasskeyOperationErrorSilent (the silent conditional create failed with a non-cancel error) and the other is a cboApiNotAvailablePostAuthenticator (API error after passkey creation). Both errors are already automatically pattern-matched to "bug in Bitwarden Chrome extension" - Corbado recognized the signature from prior occurrences. Despite the errors in the second append, the fourth subprocess eventually completed successfully with Bitwarden as the credential provider.

What makes this view powerful is the context available per error. You see the failure not as an isolated log line but as a snapshot of the complete authentication state at the moment it happened:

This explains far more than log files ever could - you can immediately correlate a failure with "this user has Bitwarden installed, no platform passkey, and the conditional create was attempted after a successful password login." That is the bridge between outcomes ("abort rate is up") and events ("conditional create fails on Windows Chrome 145 with a Bitwarden extension bug") - without this level of drill-down, a spike in your abort dashboard stays an abstract number; with it, you go from "something is broken" to a reproducible bug report in minutes.

The natural next step is to zoom out from a single process into the full user history. The user search view adds another layer of context:

This level of context is where patterns like "authentication avoided by device change" from section 4 become visible - but the user search workflow is a topic for a separate article.

Get free passkey whitepaper for enterprises.

Get for free

Native passkey deployments are harder than web. Your code is immutable once shipped, Android's fragmentation creates a 3-5x reliability gap compared to iOS and the error surfaces differ across platforms, OS versions and credential providers. Without visibility into what is actually breaking, teams discover problems reactively - weeks after users have already churned.

The debug walkthrough in section 5 shows what changes with the right tooling: a device health spike leads to an error classification, the classification leads to a trend chart, the trend chart leads to a single process with full context - existing passkeys, password managers, capabilities, the complete subprocess flow. You go from "abort rate is up" to a reproducible bug report in minutes, not weeks.

The operational discipline that follows is straightforward: block device cohorts where passkeys reliably fail, track error pattern trends to catch regressions before they impact conversion and set different thresholds for iOS and Android based on each platform's baseline. Treat passkey reliability as a continuous operational capability, not a one-time feature launch.

For the complete web browser error reference (DOMException names, error messages by browser engine), see WebAuthn Errors in Production. For platform-specific internal error code references, see GPS Passkey Error Codes (Android) and Apple Passkey Error Codes (iOS). For testing these patterns on real devices, see Testing Passkey Flows in Native iOS & Android Apps. For setting up your analytics framework, see Passkey Analytics.

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

Corbado proved to be a trusted partner. Their hands-on, 24/7 support and on-site assistance enabled a seamless integration into VicRoads' complex systems, offering passkeys to 5 million users.

Passkeys that millions adopt, fast. Start with Corbado's Adoption Platform.

Start Free Trial