Biometric unlock for an Android and iOS product

The scenario

Imagine a mobile product where returning customers want to reopen their account without entering a password every time. The proposed experience would offer biometric unlock after a successful account sign-in. The engineering problem is to make quick access convenient while preserving server-side session rules, account switching, and a clear recovery path.

Enable quick unlock after a real sign-in

The initial flow would authenticate the account through its normal server-backed mechanism. Afterwards, the person could choose to enable quick unlock on that device. The app would check platform capability and explain what the setting protects before storing any reusable session material.

Android BiometricPrompt and iOS LocalAuthentication would provide the native interaction. Biometric templates would remain under operating-system control. The product would bind access to protected key material using an appropriate platform policy, rather than treating a successful-looking screen callback as a substitute for credential protection.

Keep local unlock separate from server authorization

A local unlock would allow the app to use a protected credential or resume a permitted session. The backend would still validate expiry, revocation, and the requested operation. A successful biometric check would not restore an account that has been disabled or authorize an operation requiring fresh server verification.

The visible states would include locked, checking, unlocked, session expired, and recovery required. Cancellation would return to a usable screen. Concurrent taps would share one prompt, and a callback arriving after logout would be ignored. Account identifiers would be associated with the stored credential so that switching accounts cannot unlock the previous session.

Design for changed biometrics and lost access

Enrollment changes, device passcode changes, or invalidated keys could require ordinary sign-in again. The exact behaviour would be tested against the chosen access-control policy on supported operating systems. A fallback would recover the account through the existing authentication flow, without silently weakening the protection of the old credential.

Logout would remove the app’s reusable session material and quick-unlock association. Diagnostic events would describe states and errors without recording biometric data or tokens. Test devices would cover missing hardware, temporary lockout, backgrounding during a prompt, and a revoked refresh session.

What to validate

• Quick unlock is enabled only after an authenticated opt-in.
• Cancellation and lockout preserve a usable sign-in path.
• Expired or revoked server sessions remain invalid after local unlock.
• Logout, account switching, and enrollment changes cannot expose the previous account.

The tradeoff

Biometric unlock reduces repeated sign-in friction, but it creates a device-local credential lifecycle. The right policy depends on the product’s account risk and platform support; some actions should still request fresh authentication.