Seed Phrase Recovery Screen: An iOS Security Template

What is the seed phrase recovery screen really for?

Protecting the one secret that is the wallet itself. A seed phrase (the recovery phrase) is the human-readable form of a wallet’s private keys, usually 12 or 24 words drawn from the BIP-39 standard’s 2,048-word list. Anyone with those words controls the crypto wallet, fully and irreversibly. So the recovery screen is not a normal screen; it is a security ceremony. Its entire job is to get the phrase safely into the user’s own hands and confirm they have it, while making sure it never leaks anywhere else.

The honest framing first: this screen’s design is security, not decoration. Every choice (whether the words can be screenshotted, whether they touch the network, whether the user is forced to confirm them) is a security decision with real money on the line. A pretty seed-phrase screen that allows a screenshot to iCloud is a dangerous screen. The discipline here is unusually strict because the cost of getting it wrong is total and permanent loss, with no support line to call.

What are the non-negotiable rules?

Generate locally, reveal deliberately, confirm, and never transmit. The rules that define a correct recovery screen:

• The phrase never leaves the device. It is generated on-device and is never sent to any server, logged, or synced to the cloud. If the words touch your backend, the design is already wrong.
• Reveal is deliberate, not default. The words start hidden behind a tap-to-reveal, with a warning to be unobserved, so the phrase is not just sitting on screen.
• Force a write-down confirmation. After showing the phrase, make the user re-enter selected words to prove they recorded it, rather than letting them tap past.
• Block capture. Discourage screenshots and obscure the screen during screen recording, the same screen-recording defense any sensitive screen needs.

Break any one of these and the screen can look complete while quietly endangering the user’s funds.

How should reveal and confirm actually flow?

Warn, reveal, record, verify, in that order. The flow is a deliberate sequence: first a warning screen explaining what the phrase is and to write it somewhere offline and private; then the reveal, where the words appear (ideally numbered, in order); then the user writes them down; then a verification step where the app asks for a few words by position to confirm the backup is real. Only after verification does the wallet treat the backup as done. Skipping the verification step is the most common shortcut, and it is the one that leaves users with an unbacked-up wallet they think is safe.

If the app holds keys on-device, store them in the Secure Enclave or Keychain, gated behind biometric authentication, the same way a Face ID login gates access. But note the honest distinction: a non-custodial wallet’s recovery screen is about handing the secret to the user, while the app keeps as little as possible, ideally nothing it could leak.

What about the restore flow?

It validates the phrase locally and never phones home with it. The other half of recovery is restoring a wallet from an existing phrase: the user types their 12 or 24 words, and the app validates them against the BIP-39 wordlist and checksum, on-device, then derives the keys. The same rule holds, the entered phrase is never transmitted, and a good UI helps here with word autocomplete from the standard list and a clear invalid-word indicator, since a single mistyped word breaks the whole phrase.

The screens, the warning, the numbered reveal, the verification grid, the restore input with word validation, come as free VP0 designs built with this ceremony in mind, so an agent wires the on-device key logic onto a flow that already enforces deliberate reveal and confirmation rather than improvising a screen that leaks. The cryptography is a library; the safe, honest UX is the part that has to be designed deliberately.

Key takeaways: a seed phrase recovery screen

• The phrase is the wallet: anyone with the words controls the funds irreversibly, so the screen is a security ceremony, not a normal screen.
• It never leaves the device: generated on-device, never sent to a server, logged, or synced to the cloud.
• Reveal is deliberate and confirmed: tap-to-reveal behind a warning, then force the user to re-enter words to prove they recorded it.
• Block capture: discourage screenshots and obscure the screen during recording, since a captured phrase is a stolen wallet.
• Restore validates locally: check the typed phrase against the BIP-39 wordlist and checksum on-device, with word autocomplete, never transmitting it.

Frequently asked questions

How do I build a secure seed phrase recovery screen? Treat it as a security ceremony: generate the phrase on-device and never send it anywhere, hide the words behind a deliberate tap-to-reveal with a warning, force the user to re-enter selected words to confirm they wrote it down, and block screenshots and screen recording. If the app stores keys, keep them in the Secure Enclave or Keychain behind biometric auth. A free VP0 design supplies the warning, reveal, and verification screens with this discipline built in.

Should a seed phrase ever be sent to a server? No, never. The seed phrase is the private keys in human-readable form, so transmitting, logging, or cloud-syncing it hands an attacker total control of the wallet. A correct recovery screen generates the phrase on-device and keeps it there; if the words touch your backend at any point, the design is fundamentally broken regardless of how the screen looks.

Why force users to confirm the seed phrase? Because skipping confirmation is how users end up with wallets they believe are backed up but are not. After revealing the phrase, asking the user to re-enter a few words by position proves they actually recorded it offline, rather than tapping past the screen. Since losing the phrase means losing the funds with no recovery, the verification step is the difference between a real backup and a false sense of safety.

How does restoring a wallet from a seed phrase work? The user types their 12 or 24 words and the app validates them against the BIP-39 wordlist and checksum on-device, then derives the keys, all without transmitting the phrase. A good restore UI offers word autocomplete from the standard 2,048-word list and flags invalid words, because a single mistyped or out-of-order word breaks the entire phrase and the derived wallet will be wrong.

Should I block screenshots on the seed phrase screen? Yes, as much as the platform allows. A screenshot of a seed phrase, especially one that syncs to the cloud, is effectively a copy of the wallet, so the screen should discourage screenshots and obscure itself during screen recording. iOS cannot hard-block capture, so this is a deterrent layer, but combined with on-device generation and deliberate reveal it meaningfully reduces the chance of the phrase leaking.