AppVault encrypts files, not free-form text. On purpose.

The scope a small product can defend

Every privacy product fails in the same direction: it tries to be everything, the attack surface grows, and a sharp edge somewhere lets the whole thing down. AppVault v1 deliberately limits itself to a single primitive — an encrypted container for files you import — and refuses to grow that scope until each existing primitive has been audited and matured.

Free-form text notes look small from the outside. From the inside, they are not. A text-note feature wants to grow: rich text, autofill into other apps, browser extensions, structured fields, search across notes, sharing one note without the rest, OCR pulling text out of photos. Each of those is a new attack surface. Each one needs its own cryptographic story. Each one is a place where a single bug turns the vault into a leak. We are not in a hurry to add all of that for a feature only some users want.

The piece of text that AppVault does care about

There is one piece of text that matters: the BIP-39 12-word recovery phrase. AppVault generates this phrase during onboarding using the standard English BIP-39 wordlist (the same wordlist used by Bitcoin wallets, with a checksum word that catches typos). The phrase is shown to you once, on a single screen, and asked to be written down. It is then used internally to derive the master key that wraps your per-file AES-256-GCM keys.

The recovery phrase is the survival mechanism for device loss, theft, or a forgotten pattern. It is never uploaded anywhere by AppVault. It is not stored inside the vault. It is not stored anywhere in the app once you have written it down. It exists in exactly two places: briefly in memory on your device while you read it, and on whatever paper you wrote it on.

Where to put short secrets that are not the recovery phrase

• Passwords and login codes. Use a real password manager — 1Password, Bitwarden, Apple iCloud Keychain. They are purpose-built, audited, and integrate with iOS autofill in ways a vault should not try to imitate.
• 2FA backup codes. Either print them and store them with the recovery phrase, or store them in your password manager next to the matching login. Both are defensible.
• Cryptocurrency seed phrases. Paper. Offline. Two locations. Metal-stamped if the holdings are non-trivial. A digital backup defeats the threat model that motivated the seed phrase in the first place.
• The AppVault recovery phrase itself. Paper. Offline. Do not store it in Apple Notes, in your password manager, in a screenshot, or — as a special note — inside AppVault. Storing the recovery phrase inside the vault it would unlock is a cyclic dependency that breaks on the same day everything else breaks.

What would change our mind about adding notes

A future version of AppVault might add encrypted notes — but only if we can ship them with a deliberately narrow scope: short plain text, the same AES-256-GCM wrapping as files, no autofill, no browser integration, no form-field detection, no cross-account sharing. If that ever ships, it will be a feature in the same shape as the rest of the app: small, sharp, and limited to one job.