A backup that exists in iCloud but is unreadable, even by Apple.

Why an opt-in backup at all

A vault without a backup is a vault that vanishes the day you drop your iPhone in a lake. For some users that is the right trade-off — the photos in the vault are sensitive enough that a backup, however well encrypted, introduces an unacceptable surface. For most users, the right trade-off is the opposite: keep the photos, accept that an encrypted backup is structurally safer than no backup, and verify that the encryption is real.

AppVault leaves the choice to you. The default is no backup, no upload, no network call. If you want the safety net, enable Encrypted iCloud Backup in settings — and read the rest of this page to understand exactly what that does.

What encrypted backup is not

Three things are commonly confused with this feature. None of them is what AppVault Encrypted iCloud Backup is.

It is not iCloud Photos. iCloud Photos uploads your camera roll. Files inside AppVault are not in your camera roll, so iCloud Photos never sees them.

It is not Apple Advanced Data Protection. ADP is Apple’s account-wide end-to-end encryption for iCloud, which protects the categories of iCloud data (Photos, Notes, iCloud Drive) that Apple historically held keys for. ADP is a great thing to turn on, and it sits alongside AppVault’s backup rather than replacing it. AppVault’s encrypted backup ships ciphertext that Apple cannot read regardless of whether ADP is enabled on your account.

It is not an AppVault-operated backup service. We do not run a backend. We do not see your files. We do not see whether your backup is running. The "iCloud" in "Encrypted iCloud Backup" is your iCloud, billed to your Apple ID, stored on Apple’s infrastructure. AppVault’s only role is to encrypt the file before iOS hands it to iCloud.

How the encryption works

When you enable backup, AppVault generates a 256-bit backup key on your iPhone using Apple’s CryptoKit framework. The backup key is wrapped by the same Secure Enclave hardware key that wraps your vault key, but the two are independent — encrypting one does not give you the other. The backup key is derived deterministically from your pattern so that a second iPhone or iPad, given the same pattern, can produce the same backup key locally and decrypt the same backups.

Each file inside the vault is then sealed individually with AES-256-GCM, a fresh 96-bit nonce per file, and an authenticated header that records nothing more than the file size and a per-file index. The header itself is encrypted in the same pass. The result is a sequence of opaque blobs that iCloud Drive treats like any other file but which carries no information about your vault that an outside observer could decode.

The catalog — the list of which encrypted blob corresponds to which file inside your vault — is itself encrypted with the backup key as a whole, then split into chunks that look identical in size to the file blobs. From iCloud’s perspective, all the chunks are interchangeable. Apple cannot tell whether your backup contains one photo or one thousand.

Setup and what to expect

Setup is a single toggle in AppVault’s settings. The first time you enable backup, AppVault asks you to confirm by drawing your pattern, derives the backup key, and starts the initial upload. The initial upload runs on Wi-Fi only by default (you can change this), respects iOS background time limits, and resumes automatically when interrupted.

After the initial upload, the backup is incremental. AppVault tracks vault changes — files added, removed, or modified — and queues the encrypted deltas for upload. Most days, this means a few kilobytes of upload activity invisible inside your normal iCloud traffic.

Restoring on a second device

On a second iPhone or iPad signed into the same Apple ID, install AppVault, open the app, draw your pattern, and confirm that you want to restore from iCloud. AppVault re-derives the backup key from your pattern, finds the encrypted blobs in iCloud, downloads them, and decrypts them locally. There is no separate account, no recovery email, no confirmation step that involves an AppVault-operated server. You move from one device to another by drawing the same pattern.

What this does and does not protect against

Encrypted iCloud Backup is protection against device loss, device damage, and the practical inconvenience of starting over. It is not a defense against a forgotten pattern (the pattern is the key in both places), a compelled unlock (you can be ordered to draw the pattern on either device), or a future cryptographic break (which would affect the entire AES-256-GCM ecosystem, not just AppVault).

If you want stronger guarantees than iCloud backup can give, do not enable it. The vault on your device is already as strong as on-device cryptography gets. The backup is for users who are willing to accept that "encrypted upload to a vendor that cannot read it" is preferable to "no copy at all". That is a real choice with two defensible answers.