Password Manager Testing for native App Passkeys

With the release of iOS 17 and Android 14, the passkey landscape for native mobile apps has fundamentally changed. For the first time, third-party password managers can act as passkey providers, breaking the exclusive hold of iCloud Keychain and Google Password Manager. This allows users to bring their own trusted solutions like 1Password, Bitwarden, or Dashlane into native app authentication flows. While this is a huge win for user choice, it introduces significant complexity for developers. Your passkey implementation can behave differently across different password managers in native mobile applications. So it's important for any team to test native app passkeys and 3rd-party password managers properly.

This comprehensive guide shares our battle-tested approach to native app passkey testing with third-party password managers. While the passkey ecosystem has matured significantly in 2025, real-world implementation still requires careful validation across diverse password manager implementations. We've distilled our experience into a practical test plan that ensures your native app works seamlessly with users' preferred password managers.

The password manager ecosystem has evolved beyond platform-native solutions. Users actively choose third-party password managers like 1Password, Bitwarden, Dashlane, Proton Pass and NordPass based on their specific needs, such as cross-platform sync, enterprise features or privacy preferences. Your native iOS / Android app must accommodate this diversity without forcing users to switch their trusted password management solution.

Based on data we measure across Corbado pages, we see that only 5-10% of general users rely on third-party password managers. Even though this number might sound low, it will have a huge impact on the perception of your passkey implementation and number of support tickets if you're working in a large-scale environment. We've seen that some password managers implement the WebAuthn specification slightly differently, leading to subtle variations in user experience or even bugs.

Native iOS and Android apps provide different ways for passkey usage. On Android, you'll encounter passkey overlays and manual text-field inputs that trigger a passkey ceremony (for web apps, Android supports Conditional UI, too). iOS presents its own set of passkey overlay alongside Conditional UI and also manual text-field inputs. Moreover, there are other edge cases to check. All in all, your native application must gracefully handle:

• Passkey overlay logins that appear immediately on page load
• Conditional UI logins (iOS-only) that autosuggest available passkeys
• Text-field logins where the user provides their username before clicking on a button
• Cross-device authentication (CDA) for passkey usage with another device
• Fallback mechanisms when passkey usage is not available

Correct flag configuration determines whether passkeys work as expected across devices and platforms. Critical values include:

• Relying Party ID (rpID): Must match exactly across web and native implementations and is the domain the passkey is bound to
• User verification: Determines that the user needs to provide their local authentication
• Resident key/discoverable credentials: Enables username-less authentication (allows for Conditional UI)
• Backup eligibility (BE) and backup state (BS): Alllows cross-device sync of passkeys

Misconfigured flags don't always cause immediate failures. However, they could create subtle issues and inconsistencies like passkeys are available on one device but not synced across devices (even though the same 3rd-party password manager might be available on both devices). One of our findings in the tests was, that some 3rd-party password managers et the the BE/BS flags incorrectly and accounted for a big fraction of passkey issues.

Single-activity (Android) and single-scene (iOS) architectures require meticulous lifecycle management. When a password manager sheet appears and is dismissed, your app must preserve state, handle callbacks, and resume correctly. This is especially critical on Android, where the launchMode configuration can cause unexpected behavior.

For example, we found that setting MainActivity to launchMode="singleInstance" created problems. On some Android versions and OEM customizations, this mode causes the Passkey Credential Manager UI to open as a separate task. This not only adds a confusing, additional app entry to the "Recents" screen but can also cause the app to hang if it is backgrounded while the passkey dialog is open.

The recommended fix is to change the configuration to launchMode="singleTask". This prevents the Credential Manager from spawning a separate task, ensuring a more predictable lifecycle across different OEMs (Samsung, Google, Vivo, etc.) and reducing the risk of vendor-specific bugs. It provides a more stable foundation for testing navigation, overlays, and deeplinks.

We've observed that such lifecycle issues often masquerade as "password manager bugs" when they're actually application-level problems. Proper instrumentation and testing across different providers helps identify these patterns early.

Focus your native app passkey testing on the most widely adopted third-party password managers:

Primary targets (essential coverage):

• 1Password
• Bitwarden
• Dashlane
• Proton Pass
• NordPass

Secondary targets (based on your user base):

• Regional providers (e.g., Samsung Pass for Samsung devices)
• Enterprise solutions if targeting business users
• Platform defaults (Google Password Manager, iCloud Keychain) as baseline

Avoid the temptation to test every available password manager. Focus on providers that represent 90% of your user base. Our analytics showed that the five primary targets covered 85% of third-party password manager users in EU/USA/UK/AUS/NZ.

Before starting each test run, ensure a clean, reproducible environment:

1. Clean credential state:

• Remove all existing credentials for your RP ID
• Clear browser and app caches
• Fully sign out and sign back into the password manager
• Force-close and relaunch the target app

2. Stabilize the test environment:

• Ensure stable network connectivity (no VPNs during testing)
• Disable UI animations if automating tests
• Use consistent device orientation
• Document OS version, app version, and password manager version

Each test validates specific aspects of passkey functionality. Document results systematically using pass/fail status and detailed notes for any anomalies.

Validate graceful cancellation handling

✓ Password manager sheet opens correctly
✓ User cancels without creating a passkey
✓ App returns to login screen ✓ No orphaned credentials in the password manager
✓ UI displays appropriate retry options

Verify passkey creation after authentication flow

✓ Local authentication launches reliably
✓ Biometric authentication completes successfully
✓ Credential created with correct RP ID
✓ App transitions to authenticated state without loops

Test standard authentication scenarios

✓ Passkey Overlay UI appears or user provides username in text-field scenario ✓ Biometric scan and single biometric prompt leads to successful authentication
✓ No selection loops or sheet re-appearances
✓ Session remains stable post-authentication

Validate in-app passkey management

✓ Correct RP ID, discoverability and BE/BS flags
✓ App remains authenticated after creation
✓ Password manager updates immediately with correct labels

Test credential lifecycle management

✓ Delete passkey in settings ✓ Passkey login is not possible
✓ Suitable fallback option is offered

Validate app-to-web portability

✓ Browser recognizes app-created passkeys
✓ Selection sheet shows correct RP association
✓ Authentication completes without QR/CDA detour

Test web-to-app credential sharing

✓ App surfaces web-created credential in selection
✓ First-attempt authentication succeeds
✓ No forced password fallback

Verify passkey sync from native app to desktop browser

✓ App-created passkey syncs to desktop password manager ✓ Synced passkey works seamlessly in desktop browser ✓ No QR code / cross-device flow is triggered ✓ Authentication completes without loops or errors

Verify passkey sync from desktop browser to native app

✓ Desktop-created passkey syncs to mobile password manager ✓ Native app correctly surfaces the synced passkey ✓ Authentication succeeds without password fallback ✓ Logs tie assertion to the correct credential ID

Validate phone-as-security-key scenarios

✓ Phone offers app-created credential for web CDA
✓ No false "no passkeys available" errors
✓ Web session completes after mobile biometric

Our extensive testing revealed several recurring patterns that affect third-party password manager passkey integration:

Problem: Credentials created on one device may not immediately appear on others.

Solution: Implement retry logic with exponential backoff. Provide manual refresh options for users experiencing sync delays.

Problem: Password manager behavior varies significantly between OS versions, especially on Android 14+ and iOS 17+.

Solution: Maintain a compatibility matrix and adjust flows based on detected OS version. Consider minimum version requirements for optimal experience.

Successfully implementing third-party password manager passkey support in native apps requires methodical testing and attention to detail. Our comprehensive test plan, refined through real-world testing, provides a solid foundation for validating your passkey integration.

Key takeaways for production deployment:

1. Test systematically: Use our test plan as a baseline, adapting it to your specific use cases
2. Respect user choice: Support the password managers your users prefer, not just platform defaults
3. Monitor continuously: Implement comprehensive logging to catch edge cases in production
4. Document thoroughly: Maintain clear records of provider-specific behaviors and workarounds

The passkey ecosystem continues to evolve rapidly. Password managers regularly update their implementations, operating systems introduce new features,and the WebAuthn specification itself advances. By establishing a robust testing framework now, you'll be prepared to adapt as the technology matures.

We'll continue updating our SDKs and testing methodology as new patterns emerge. The investment in comprehensive third-party password manager testing pays dividends in reduced support burden and improved user satisfaction. After all, authentication should just work - regardless of which password manager your users choose.