The vault is not in iCloud Backup. By design.

The boring iOS attribute that does the work

iOS exposes a per-file attribute called NSURLIsExcludedFromBackupKey. When that key is set to YES on a directory, iOS quietly drops the directory from every system backup — iCloud Backup, iTunes Backup, Finder Backup. The user does not see the exclusion in their backup settings, the data just is not included.

AppVault sets this flag on the vault directory the moment the directory is created. It is one line of code (setResourceValues({ URLResourceKey.isExcludedFromBackupKey: true })) and it is one of the first things the app does. The vault never spends an instant being backup-eligible.

Why this matters, in plain terms

A backup that contains vault ciphertext is a backup that can be restored. A restored backup is a copy of your files on a different device. A different device can be:

• A device an investigator subpoenas through Apple.
• A device a thief, partner, or family member sets up with your Apple ID and password.
• A device that ends up in a refurb pipeline still attached to your iCloud, because someone forgot to sign out.

AppVault closes all three by never being in the backup in the first place. The vault is not on the second device; it is not in any subpoena; it is not in any leaked iCloud archive. The threat model is reduced from "trust the chain of custody of Apple’s backup infrastructure" to "trust the device in my hand right now".

The Keychain belt-and-suspenders

Even if the directory exclusion were somehow bypassed, the ciphertext would be unreadable on a second device. The master keys (the small handful of secrets that unwrap the per-file AES-256-GCM keys) live in the iOS Keychain, pinned to kSecAttrAccessibleWhenUnlockedThisDeviceOnly. That access flag is iOS’s strongest "do not migrate this" signal. It explicitly forbids:

• Sync to iCloud Keychain.
• Restore from any encrypted iPhone backup onto a different device.
• Inclusion in any iTunes / Finder backup.

A vault that traveled in ciphertext form would still be useless without these keys, and these keys are pinned to a single device by Apple’s own platform security model.

Surviving device loss: the recovery phrase

The cost of this design is that a brand-new iPhone, signed into the same Apple ID, does not recover your old vault. To survive that scenario, AppVault generates a BIP-39 12-word recovery phrase during onboarding, the same kind of phrase that cryptocurrency wallets use. The phrase is shown once. Write it down on paper, store it offline, and never type it into a cloud-synced note. On a new device, choose "I have a recovery phrase" during setup, draw a new pattern, and enter the phrase — the vault is reconstituted from the phrase plus the new pattern.

You can regenerate the recovery phrase later in Settings → Regenerate Recovery Phrase. The old phrase is invalidated; the new phrase is the only valid one from that point forward. If you lose both the device and the phrase, the vault is unrecoverable. That is by design.

What is not happening, contrary to common assumption

• The vault is not uploading to AppVault servers. There is no AppVault server. We operate no backend that holds user content.
• The vault is not uploading to your iCloud as ciphertext blobs. Some competitors do this and call it "encrypted iCloud backup". AppVault does not. The exclusion flag prevents it.
• The vault is not shared across your Apple devices automatically. Each iPhone or iPad you install AppVault on starts as a fresh, empty vault. The recovery phrase plus a pattern is how you opt in to cross-device parity, manually, when you choose to.