Hidden, locked, encrypted — three words that are sold as one
Almost everyone has a handful of files they would rather not have appear when they hand someone their phone to show a photo. The apps that promise to solve this range from a folder with a picture of a padlock on it to something genuinely unreadable without a key, and from the outside they look identical. The difference only becomes visible on the day it matters.
- 0 copies Keys a well-built vault keeps anywhere but your own device
- 2 ways in The passcode you remember, and the recovery code you stored somewhere else
- 1 rule Lose both and the files stay unreadable — to you, and to whoever wrote the app
What “hidden” usually turns out to mean
The Hidden album in Photos is the version most people already use, and it is worth being precise about it: it moves items out of the main grid and, since iOS 16, puts Face ID in front of the album itself. What it does not do is change the file. The photo is stored exactly as it was, it still syncs to iCloud Photos, it is still returned to anything that has been granted access to your photo library, and anyone who knows your device passcode can open it because the device passcode is the fallback for Face ID. It is tidying, not protection — and for the common case of a friend scrolling one picture too far, tidying is genuinely enough.
The next tier up is a folder behind a passcode, which is what most apps calling themselves a vault actually are. There is a PIN screen, and behind it a list of files that live on disk in the ordinary way. This stops a person holding your unlocked phone, which is a real and common threat. It does nothing at all against a full backup, a forensic extraction, or anything else that reads the storage rather than the app.
The top tier is encryption with a key of its own. The files are transformed on the way in, and what remains on disk is meaningless without the key: not a preview, not a file name, not a length that gives the contents away. Whoever copies the storage gets noise. This is the only version where the phrase “nobody else can open it” is literally true — and it is also the only version where losing your own key means losing the files, which is the trade nobody advertises.
The three approaches, measured against what you are actually worried about
Pick by threat, not by marketing. Most people need the middle one and buy the third; a few genuinely need the third and settle for the first.
The words on the feature list, translated
These terms are used precisely by people building this and loosely by people selling it. Knowing them is most of the defence.
- Encryption at rest
- The file is unreadable while it sits on disk, not merely while it travels. This is the claim that matters for a vault, and the one most often implied without being made.
- AEAD (authenticated encryption)
- Encryption that also detects tampering — AES-GCM and ChaCha20-Poly1305 are the two in ordinary use. Without it, a file can be altered in ways that are not obvious when it is decrypted.
- Key derivation (KDF)
- Turning a short passcode into a real key through deliberate slowness, so that guessing millions of PINs costs real time. A vault that skips this is a vault with a four-digit key.
- Envelope / key wrapping
- The files are encrypted with one random master key, and that key is then encrypted separately by your passcode and by your recovery code. It is why changing the passcode takes a moment rather than re-encrypting everything, and why two different secrets can both open the same vault.
- Recovery code
- A long string generated once, at setup, which wraps a second copy of the master key. It is the only other door. It exists precisely because there is no account to reset, and it is worthless if it lives only on the device it protects.
- Data Protection
- The iOS layer that ties a file’s availability to the device being unlocked. It is genuinely strong, and it is not a substitute for the app’s own key — it protects against the device being taken, not against the phone’s owner being asked to open it.
- Decoy vault / plausible deniability
- A second, believable set of contents opened by a different passcode, for the situation where you are not the one deciding whether the vault gets opened. A real feature with real limits: it helps against a person, not against an analyst who counts the bytes on the disk.
Setting up a vault so that it still opens in two years
The failure mode for encrypted storage is almost never an attacker. It is the owner, eighteen months later, with a passcode they set once and never typed again.
-
Choose a passcode you will actually still know
Not a variation of something you use elsewhere, and not a random number you will type twice. Something you can reconstruct from memory in a year, because you will not be using it daily.
-
Store the recovery code somewhere the phone is not
A password manager, a note in a safe, a printed line in a drawer. On the device it protects, it is decorative. Sent to yourself by email, it is as secure as your email account — which may be fine, as long as you have decided that on purpose.
-
Decide what a backup should do here
Including the vault in your iCloud or computer backup means the encrypted files survive a lost phone. Excluding it means a smaller backup and nothing recoverable if the device is gone. Both are defensible; drifting into one without noticing is not.
-
Move the originals in, then delete them from where they were
In that order, and only after the vault confirms each item arrived. An import that deletes first is one interrupted transfer away from losing the file entirely — and the deletion should go through the system’s own confirmation, not quietly.
-
Lock it, and open it once from cold
Close the app, reopen, type the passcode rather than using Face ID. This catches the case where you have been getting in biometrically and the passcode you set was never really committed to memory.
-
Check what is left behind
Search the main library for the file name. Look at recently played, at the widget, at the lock screen while something from the vault is playing. A vault that leaks its contents through a “now playing” title is a vault with a window in it.
The whole exercise takes about five minutes and is the difference between a vault and a folder you feel good about.
The situations people actually run into
Worth reading before setup rather than after, because two of these rows cannot be fixed afterwards.
| Situation | What happens with a well-built vault |
|---|---|
| New phone, restored from backup | The encrypted files and the wrapped keys come across; the passcode itself does not, because it is stored in a way that does not travel. You get in once with the old passcode or the recovery code, then set a new one. |
| Forgot the passcode, have the recovery code | The recovery code unwraps the master key, the vault opens, and you immediately set a fresh passcode. Nothing is re-encrypted, so it takes a moment rather than an hour. |
| Lost both | The files stay on disk as ciphertext and stay unreadable. This is the outcome the design guarantees, and no app can offer both this guarantee and a way around it. |
| Deleted the app | Everything inside goes with it, exactly as with any app’s private storage. Export before uninstalling — a vault worth using has a single action that puts everything back into ordinary folders. |
| Someone knows your device passcode | They reach the device, not the vault: the vault key is derived from its own separate passcode. This is the case a decoy vault is designed for, when the person is standing next to you. |
| Backup excluded, phone lost | The encrypted files were never copied anywhere, so there is nothing to restore. A deliberate choice for some people and an unpleasant surprise for the rest. |
Screenshots and screen recordings are the one gap no iOS app can close: while you are looking at something, the system can capture it. Any app claiming otherwise on iPhone or iPad is describing something it cannot do.
How to judge a vault app before putting anything irreplaceable in it
- Does it name the encryption, or just say “military grade”?
AES-256-GCM or ChaCha20-Poly1305 are answers. “Bank-level security” is a decoration, and usually appears where there is nothing to name.
- Does it explain the recovery path honestly?
An app that offers to email you a reset link is telling you it holds a key. That may be an acceptable trade — but it means the vendor can open your vault, and it should be said out loud.
- Can you get everything out in one action?
A vault should be a room you can leave. If exporting means opening files one at a time, your data is hostage to the app continuing to exist.
- Does it hold existing content hostage to a subscription?
Metering new additions is reasonable. Locking you out of what is already inside when a subscription lapses is not, and it is worth checking before rather than after.
- What leaks around the edges?
Search results, Spotlight, thumbnails in a shared cache, recently-played lists, widgets, the lock screen while audio plays, a file-sharing server the app runs. Each of these has leaked a vault at least once.
- Where do the thumbnails live?
A preview image is the file. Thumbnails written into a system-wide cache directory undo the encryption for everything anyone would actually want to see.
- Does anything go to a server?
A vault has no reason to phone home. If it uploads, the question of who holds the keys becomes the only question that matters.
Where the platforms differ
The device most likely to be handed to somebody else, which is why the everyday threat model dominates. Face ID plus a separate vault passcode covers it; the device passcode should not be the thing that opens the vault.
More often a shared or household device, and more often the one left on a table. A second lock earns its place here more than anywhere, and the larger screen makes a decoy set of contents look more convincing rather than less.
FileVault encrypts the whole disk when the Mac is off, which is a different and complementary layer: it protects a machine that has been taken, while a vault inside an app protects against whoever is already logged in.
Questions people ask
Is the Hidden album in Photos private?
It is hidden, not private. Since iOS 16 the album itself asks for Face ID, but the photos are unchanged: they sync, they remain in your photo library for any app you have granted access, and your device passcode opens them because it is the fallback for Face ID. For a curious friend that is enough. For anything else it is not what it appears to be.
Can the people who wrote the app open my vault?
With a properly built vault, no — the key is derived from your passcode on your device and never exists anywhere else. The way to check is the recovery story: an app that can email you a reset link necessarily holds something that opens your vault. That is not automatically dishonest, but it is the opposite of what “only you can open it” means.
What if someone makes me open it?
This is what a decoy vault is for: a second passcode that opens a believable, harmless set of contents, so that complying and protecting the real contents are the same action. It is designed against a person in front of you, not against forensic analysis of the storage, and it works best when the decoy has plausible things in it rather than being empty.
Does a vault protect a phone that is stolen while unlocked?
Yes, as long as the vault has locked itself again — which is exactly what the auto-lock setting decides. A vault set to stay open for the whole session is open on a stolen unlocked phone. This one setting does more work than the choice of cipher ever will.
Can encrypted video be played without decrypting the whole file first?
Yes, when the file is encrypted in chunks rather than as one block. The player asks for the part it needs, that chunk is decrypted in memory, and seeking still works. The alternative — writing a decrypted copy to a temporary file to play it — defeats the encryption for as long as playback lasts, and is worth asking about.
How the vault in FoxDL is built
Stated in detail, because the point of everything above is that vague claims are not claims.
- Files are encrypted with ChaCha20-Poly1305, chunk by chunk, with a random master key generated once on your device. A video streams straight out of the vault: each chunk is decrypted in memory as the player reaches it, and no decrypted copy is ever written to disk.
- Two envelopes, one key. The master key is wrapped once by your vault passcode and once by your recovery code. Changing the passcode rewraps the envelope in milliseconds instead of re-encrypting your library, and either secret opens the vault on a new device.
- The vault has its own passcode, separate from the app lock, with Face ID or Touch ID and its own auto-lock timer. The biometric copy of the key sits in the Keychain requiring your presence, and is bound to that device.
- Nothing readable is left on disk. Files are stored outside your Documents folder under names that carry no meaning; the real names and the folder tree live only in an encrypted catalogue, and thumbnails stay inside the vault rather than in a shared cache.
- Nothing leaks around the edges. Library search, Spotlight, Wi-Fi Transfer, device-to-device sending and the share inbox do not see the vault. In playlists and recently-played, vault items appear as a masked row, and the lock screen shows a generic title while one is playing.
- Camouflage and a decoy vault. The vault can wear a name and icon you choose with no lock badge on it, opening straight into a harmless set of files, with the real vault behind a gesture you pick. A second passcode opens the decoy, and an optional setting makes Face ID and the device passcode open the decoy too — so the real one answers only to a passcode you never have to demonstrate.
- Your files are never held hostage. Everything inside stays viewable, playable and exportable regardless of subscription state, and one button in the vault settings puts all of it back into ordinary folders.
- The free version holds 15 items, counted live, so removing one makes room. Beyond that it is FoxDL Pro — and this is the one feature with no rewarded-video route, because advertising has no business in a privacy feature.
Set the recovery code aside somewhere other than the phone before you move anything in. If the passcode is forgotten and the code is gone, we cannot open the vault for you and neither can anyone else — that is the guarantee working as designed, and it is the reason the code exists.
Questions people ask about this
- How do I hide files, and how secure is the vault?
- What happens if I forget the vault passcode or lose the recovery code?
- Can I hide the vault itself, or open a fake one if somebody makes me unlock it?
- Does the vault survive a new phone or a restore from backup?
- Can I play videos and music straight from the vault?
- How do I move photos into the vault, and are they deleted from Photos?
- Can I download a file straight into the vault?
- How many files can I keep in the vault without Pro?
- How do I get files back out of the vault?
- Does anything from the vault show up elsewhere in the app?
Keep reading
What a media app on your phone can see, and what it should never send
What a media app can see, how to read a privacy label, and why a lock is not encryption.
Where your files actually live on an iPhone, and who can see them
The sandbox, where downloads actually go, and why renaming a file breaks so many apps.
Five ways to get a large file onto an iPhone, and when each is the right one
Wi-Fi, device to device, cloud, WebDAV or a drive — which route suits which job.
Your library, finally in one place.
Free to download. No account, no sign-up, and the whole feature set is in the free version.