Delete that actually removes the bytes — not just the filename.

Why "delete" usually does not delete

The mental model most people have of deletion is that the file is physically erased — the bytes scrubbed off the disk. The reality on every modern filesystem is closer to a library reshelving operation. The directory entry that says "this filename lives at these storage blocks" gets removed. The blocks themselves get marked as available for new writes. The original bytes stay there, in place, until some future write happens to land on those exact blocks.

How long that takes depends on how much free storage you have and how much data you write afterwards. On an iPhone with 80% of its storage free, the original bytes of a "deleted" file can persist for months. Forensic tools that read raw storage — bypassing the filesystem layer — recover those bytes in full.

The conventional fix is to overwrite the bytes before unlinking. Write random data over the original. Write again. Write a third time. After the third pass, even if a forensic tool reads the raw storage blocks, what it finds is meaningless noise.

How AppVault’s shredder works

When you choose Shred on a file inside AppVault, three operations happen in sequence:

1. The encrypted file blob in AppVault’s sandboxed container is opened for write. A buffer the same size as the blob is filled with cryptographically random bytes from SecRandomCopyBytes and written over the existing data. The write is synced to storage before the next pass begins.
2. The same buffer is XORed with 0xFF (the bitwise complement of the random pass) and written again. This is the second pass.
3. A fresh random buffer is generated and written as the third pass. The file handle is closed and the now-overwritten blob is unlinked from the filesystem.

The catalog inside the vault is updated to remove the file’s entry, and the catalog is re-encrypted as a whole. After the operation completes, the vault behaves exactly as if the file had never been imported in the first place.

The honest caveat about iPhone flash

Three-pass overwrite was designed for magnetic media — spinning hard drives where the relationship between a logical block and a physical location on the platter is one-to-one. Modern flash storage breaks that assumption. The flash controller maintains a logical-to-physical mapping that it adjusts to spread write wear evenly across the chip. When AppVault writes "overwrite pass one" to logical block N, the controller is free to send that write to a different physical page than the one block N previously occupied — leaving the original physical page intact, marked as "to be erased eventually".

This means file-level shredding on flash is structurally less complete than file-level shredding on a hard drive. It is the honest answer that every iOS file shredder’s documentation should include, and most do not.

Two facts make this caveat less alarming than it sounds.

First, every file inside AppVault is already encrypted with AES-256-GCM before it is written to flash. A wear-leveled remnant — even one that survives the shred operation — is ciphertext that requires the vault key to make sense. The vault key is derived from your pattern and bound to the Secure Enclave; the remnant ciphertext is decorative without it.

Second, iOS itself applies device-wide encryption to flash storage using an effaceable-storage scheme. When you factory-reset an iPhone or use the "Erase All Content and Settings" option, iOS does not overwrite every page of flash — it discards the device-wide encryption key, which makes every byte on the device cryptographically random in one operation. This is the canonical secure-wipe operation for iPhone. The File Shredder is a useful per-file complement for live devices; the factory reset is the canonical operation before selling.

When to actually use it

Three reasonable use cases for the shredder.

Before selling, donating, or trading in

Run the shredder over any vault file with above-average exposure if recovered — sensitive documents, ID scans, medical photos, signed contracts you no longer need. Then perform iOS’s "Erase All Content and Settings" to discard the device-wide encryption key. The combination is as close to forensically complete as iPhone storage gets.

After a specific document is no longer needed

A one-off — a passport photo for a single visa application, a screenshot of a 2FA recovery code you have now stored elsewhere — gets the shredder rather than the regular delete. The encrypted blob disappears immediately instead of sitting in Trash for thirty days.

When the threat model includes targeted physical forensics

If you are a working journalist, a lawyer with privileged photo evidence, or a medical professional documenting case material, the cost of leaving recoverable ciphertext on the device is small but non-zero. The shredder reduces that cost to as close to zero as on-device flash storage permits.

What the shredder is not

Not a replacement for the iOS factory reset. Not a defense against an adversary who has the vault key. Not undoable. Not faster than a regular delete (each pass writes the full file size). Not free in storage I/O terms (a 50 MB video takes a few seconds to triple-write).

It is, simply, the right operation when "delete this so thoroughly that I do not need to think about it again" is the answer you actually want.