App locks: separate PIN, biometrics and timing

Distinguish setting a PIN from enabling a shortcut.

Voice Recorder & Transcribe shows Biometric unlock and Create PIN Code as separate rows. Deep Cleaner presents a Private Space prompt with Set Passcode and Later. These screens illustrate different entry states: configuring an available unlock method versus introducing a protected area that has not yet been set up.

Design the dependency deliberately. If your product requires a passcode before biometrics, explain that order and leave setup incomplete until the credential is confirmed. If it uses device-owner authentication instead, do not ask for an unnecessary app-specific PIN just because another product does. The setting should describe the real authentication policy.

Make cancellation safe and literal. Later should defer setup, not leave the feature appearing enabled. After a failed confirmation, preserve only what is appropriate and explain the next step without exposing secret input. Never display an enabled protection switch merely because a person opened the setup sheet or granted a permission.

Name the protected space, not just the technology.

Vault separates passcode management, account actions and general settings. Cleaner Phone Storage Cleanup puts Disable Passcode, Change Passcode and Enable Face ID under a Secure Vault heading, separate from its email account controls. The grouping matters because securing one vault is not necessarily securing every screen in a multi-tool app.

Use the noun people recognize: this vault, locked notes, the whole app or a specific account workspace. Explain whether previews, recent-item lists and background app snapshots are included. Do not use a broad Private label if other product surfaces still reveal the protected content. Scope is a product behaviour, not a decorative section title.

Keep removing a local passcode, signing out and deleting an account visibly distinct. They change different things. A user should not need to infer from a red row whether it disables an access gate, disconnects a service or removes data. Confirm consequential changes with the affected space and an accurate description of what remains.

Do not let a biometric confirmation overstate the result.

Photo Maker displays application-password and facial-recognition controls with a Face ID confirmation overlay. Genie Phone Storage Cleaner separates Use Passcode and Use Face ID from Remove After Import preferences. One confirms an authentication moment; the other shows that unlocking and source-file removal are different settings.

A successful biometric prompt should confirm only the action it actually authorizes. It does not prove that all content is encrypted, that imported originals were removed or that a remote account is secure. Keep these claims out of the success copy unless they are independently established by the product.

For implementation context, Apple’s Local Authentication documentation describes evaluating authentication policies and receiving a result. The UX must still distinguish unavailable authentication, cancellation and success. The fallback offered depends on the chosen policy and the app’s implementation; do not invent a universal fallback contract from a Face ID label.

Say what starts the relock interval.

Purple Ocean offers immediate locking or delays of one or fifteen minutes. OnPhone includes an immediate option and several delayed autolock choices alongside PIN and Face ID controls. The visible duration is useful, but the essential implementation question is when that duration begins.

After leaving the app, after the last interaction and after the last successful unlock are different clocks. Choose the rule deliberately and describe it next to the options. A person checking another app for a few seconds should be able to predict whether returning will require authentication. Do not let a familiar time picker hide an undefined trigger.

Test quick switching, an extended background period and a fully restarted app. A grace period should not accidentally persist across a state where the product intends to lock. Conversely, repeatedly interrupting an active editing task without explanation can train people to disable protection. Assess both the security requirement and the recoverable user task with engineering.

Protect the places where content can still appear.

Freenotes includes a setting for keeping locked notes out of search results, along with Face ID and an exit-related delay. Ash explains that its lock uses the same authentication method as the phone and offers verification frequency choices based on opening or inactivity. These examples make different aspects of protection explicit.

A locked editor is only one surface. Review search snippets, notification previews, widgets, exports, recent items and app-switcher snapshots according to your product’s scope. If a surface cannot be protected by the same gate, explain the limitation rather than treating the presence of a lock screen as the end of the design work.

Use ScreensDesign Pro to compare the setting with the actual return-to-app and protected-content sequence. A configuration screenshot cannot show whether a note remains readable in another surface or whether a cancel action briefly reveals content. Those transitions need deliberate product testing, not assumptions based on a reassuring icon.

Model protection as a state, not a cosmetic switch.

Separate configured policy, currently authenticated session and the content scope the gate covers. On launch or return, resolve whether authentication is required before rendering protected content. Do not briefly display the private screen while waiting to learn whether the lock should appear. This requirement should cover interrupted and restored navigation, not only the standard home route.

Handle unavailable biometrics, changed device enrollment, cancellation and repeated failure according to the verified policy. Keep a permitted recovery route understandable without promising that a forgotten app PIN can always be reset without loss. Recovery and credential removal are security decisions for the product team, not copywriting opportunities to invent convenient behaviour.

A lock should not discard unsaved work simply because the app went into the background. Preserve the draft through the appropriate secure mechanism and reveal it only after the intended authorization. Avoid logging secret input or private content in diagnostics. Support information should describe the failure without becoming another way to bypass or expose the protected area.

Test return paths and cancellation before celebrating setup.

Use a dedicated test account with disposable content. Cover first setup, abandoned setup, changed PIN, disabled biometrics, system cancellation, quick app switching, a long background period and a cold launch. Verify that protected surfaces remain covered throughout transitions, including the moment before the authentication result returns.

Measure setup abandonment, repeated unlock failures and unexpected relock reports. Do not interpret more successful prompts as better protection, or fewer prompts as better usability. Check whether the configured policy is enforced and whether legitimate users can resume their intended task without losing work.

Provide readable labels for switches and selected timing options. Explain disabled settings without relying on faded text alone. At large text sizes, keep recovery information visible rather than clipping it inside a fixed-height card. A biometric icon should have a useful accessible name but must not reveal protected content in an announcement.

Review the local-lock contract.

Use these checks on a working build, not only on the polished reference state.

• ✓Name the exact protected area and surfaces.
• ✓Separate setup, current session and unlock method.
• ✓Define the event that starts the relock timer.
• ✓Test cancellation before protected content renders.
• ✓Verify recovery and removal with engineering.
• ✓Preserve appropriate drafts without exposing them.

Related design decisions

Use the privacy settings examples for the broader preference architecture while keeping the local access gate’s scope precise.

Account authentication remains a separate contract. Compare the mobile login screen examples rather than treating an app PIN as a replacement for account identity and authorization.