Most photo vault apps hide your photos. Few encrypt them. We checked 69 apps.

Before building a photo vault for iPhone, we wanted to know what the existing ones actually promise. So we read the App Store listings of every photo vault app we could find: 69 apps, collected from eight vault-related searches on the US App Store on October 30, 2026.

Everything below comes from public App Store listings, and the full dataset is a CSV if you want to check our counting.*

The numbers

"Popular" means 1,000+ ratings on the US App Store (34 of the 69 apps).

Two things jumped out.

Privacy apps that track you. Three in four popular vault apps declare, in their own privacy label, data used to track you across other companies' apps and websites. That's almost always ad and analytics SDKs in free apps. For a category whose entire pitch is privacy, it's a strange default.

Almost nobody says how the photos are protected. Fewer than half mention encryption at all. Among the 34 popular apps, exactly one names the cipher. An app may encrypt without saying so, but a listing that never mentions it gives you nothing to verify.

This measures what apps say, not what they do. We didn't reverse-engineer anyone. But for users, the listing is usually all they have.

Hiding vs encrypting on iOS

If you're an iOS developer, your first reaction might be: iOS already encrypts everything. It does. Every file on an iPhone is encrypted at rest by Data Protection, with keys tied to the device passcode. So the real question isn't "encrypted or not". It's whose key protects the photos, and when is it available?

A vault that only hides photos usually works like this: files sit in the app's container under the default protection class, and a passcode screen in the UI decides whether to show them. Those files are protected by the device passcode. That means they're readable:

• whenever the phone is unlocked, by anything with access to the container,
• in an unencrypted local backup made by Finder or iTunes, where app data is stored readable,
• by the developer's own "forgot passcode" flow, because the app can always get to them.

A vault that encrypts adds its own layer: each file is encrypted with a key derived from the vault's secret, not the device's. Unlock the phone, copy the container or pull it from a backup, and you still have ciphertext.

The one-question test

Ask the developer: "If I forget my vault passcode, can you get my photos back?"

If the answer is "yes, just verify your email", the photos aren't encrypted with something only you hold. They're hidden. A real encrypted vault can't reset your passcode. It can only offer a recovery key that you saved yourself.

Why "military-grade" tells you nothing

"Military-grade" almost always means AES-256, which is a fine cipher. But the cipher is rarely where things go wrong. The details that decide whether photos are actually safe:

• Mode. AES-GCM is authenticated: it detects tampering. Some older modes don't.
• Key derivation. Is the passcode stretched with something slow and memory-hard, like Argon2id? A 6-digit PIN through a fast hash falls to brute force in seconds once the files are copied off the device.
• Key storage. Is the key stored right next to the data, or bound to hardware like the Secure Enclave so guesses have to happen on the phone?
• Per-file keys. Does every file get its own key, or is one key reused for everything?
• Recovery. Is there a recovery key that only the user holds, or a server-side reset?

A listing that names these is making claims someone can check. "Military-grade" isn't.

Encryption raises the stakes on losing photos

There's a catch we didn't expect when we started. In a second study we read the 10,829 most recent App Store reviews of 53 vault apps (full write-up). One in four was one star, and in the past year 27% of one-star reviews were about lost photos.

Real encryption makes this harder, not easier. If only the user's key can open the files, there's no support ticket that brings them back. So an honest encrypted vault has to take recovery seriously:

• a recovery key generated at setup and shown to the user,
• a backup that's encrypted before it leaves the device,
• a way to test that the backup actually restores, before you need it.

What we built

For context, here's how Easy Vault handles the points above. The full details are on our security page.

• AES-256-GCM, a separate random 256-bit key per file. File keys are wrapped by a vault key.
• Argon2id to turn the passcode into a key, combined with a key held in the Secure Enclave, so guesses have to happen on that iPhone, slowly.
• iOS Complete Protection on vault files, so they can't be read while the phone is locked, not only before the first unlock after a restart.
• No account, no servers. Nothing to breach on our side, and no reset flow that could bypass the key.
• A recovery key shown at setup, and an iCloud backup that's encrypted on the device first. The app can check that your key opens the backup.
• Keys wiped from memory when the app goes to the background, and a blurred app-switcher snapshot.

It's also honest about its limits. It can't protect against someone who knows your passcode or makes you open the app (that's what the decoy passcode is for), or against a phone already compromised by malware with full device access.

If you're choosing a vault app

1. Check the privacy label. "Data Not Collected" is rare in this category. Look for it.
2. Look for a named cipher and key derivation, not adjectives.
3. Ask the reset question. A yes means hidden, not encrypted.
4. Make sure there's a recovery key and a backup, and test them.

And if you're building one: write the security page first. If you can't explain where the key lives in plain words, users can't trust it, and neither should you.

The dataset, method and per-app breakdown are in our photo vault app privacy report. Questions about the method are welcome in the comments.