App-Vault 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. App-Vault 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 App-Vault does care about

There is one piece of text that matters: the BIP-39 12-word recovery phrase. App-Vault 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 App-Vault. 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 App-Vault 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 App-Vault. 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 App-Vault 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.