Is a local vault app actually secure, or can someone break the encryption?

The encryption holds against someone who has the phone and not the PIN, which covers the situation most users worry about. It does not hold against a forensic examiner with the handset, time, and tooling, or against malware already running on a rooted device. We build for the first case and say so in writing.

What happens when a user forgets the PIN?

If the PIN is the only secret that wraps the file key, nobody can recover the vault, including us. That is what makes the encryption meaningful. At setup we offer a recovery wrap through a security question or recovery phrase, a recovery file the user stores elsewhere, or a product that clearly states the vault is lost with the PIN.

Can you add a recovery backdoor so our support team can help locked-out users?

A backdoor that decrypts one user's vault decrypts every user's vault, and it becomes the most valuable thing in the product to steal. We build recovery that the user controls instead: a second wrap of the data key that only they hold. Support can help with the app, not with the key.

Do users need an account or a server?

No. The vault works offline with all content on the device, and there is no server copy to leak or subpoena. Sharing or multi-device sync would be a separate design with its own key exchange, because it changes the threat model, so we would scope it as its own phase.

How do you stop screenshots and app-switcher previews from showing vault content?

On Android we set FLAG_SECURE on vault screens, which blocks screenshots and screen recording and blanks the recent-apps thumbnail. On iOS we blur the interface when the app leaves the foreground and detect screen recording where the platform reports it. We also keep decrypted thumbnails out of the system gallery and clear the clipboard on a timer.

Private Vault & Encrypted Storage Apps

Private vault apps for iOS and Android: PIN or biometric unlock, encrypted on-device storage, decoy access, and screenshot protection.

See our work:

CalculatorX (HideX)→Calculator Lock - Android App→Camera Filters→

A person installs a privacy utility because something on their phone should not be seen by whoever picks it up next: a partner, a colleague, a child, a technician at a repair desk. The product fails at the first screen that shows the content in the app switcher, at a folder called Vault that the system gallery indexes anyway, or at the moment the PIN is forgotten and the files go with it.

We build vault apps for publishers and product teams who want sensitive content to stay on the device, with the limits of that model written into the product.

What a local vault protects against

The realistic threat for a consumer privacy app is a person holding the phone, not an attacker with a forensics lab. Somebody knows the device passcode and scrolls through the photo library. Somebody tries a few obvious PINs.

A vault works against that when three things hold at once. Content is encrypted with a key the operating system will not hand over on its own, the app does not advertise what it stores, and the unlocked state is brief.

A vault app does not defeat a forensic examiner who has the handset, the time, and the right tooling. It does not defend against malware that already holds system-level privileges on a rooted or jailbroken device, and it cannot stop somebody reading the PIN over a shoulder. On-device encryption raises the cost of casual access; it does not make secrets undiscoverable.

Who this suits

Consumer utility publishers adding a private gallery, a private browser, or a hidden notes area. Professional apps where a client file has to stay on the device, in field surveys, case notes, or scanned documents. Products where discretion is part of the value, including a cover interface that gives nothing away to someone glancing at the screen.

What we deliver

Key derivation and encryption choices

A four or six digit PIN is a weak secret, so we never use it as the encryption key directly. We derive a key from the PIN and a random per-install salt with Argon2id, or PBKDF2 at a high iteration count where a platform library makes that the sounder choice. Content is encrypted with AES-GCM or ChaCha20-Poly1305, each file with its own nonce, and the authentication tag is verified on read, so a tampered file fails to open.

The data key is separate from the PIN: one random key encrypts the files, and the PIN-derived key wraps it, so changing the PIN rewraps one small blob.

Keys live where the platform protects them: Keychain items with kSecAttrAccessibleWhenUnlockedThisDeviceOnly on iOS, Keystore entries on Android, and hardware-backed keys on devices with a secure element. ThisDeviceOnly keeps the key out of a device backup. Plaintext exists in memory while content is on screen, and temporary viewer files are removed when the screen closes.

Biometric unlock and its fallbacks

Face ID, Touch ID, and Android BiometricPrompt handle the daily unlock through the platform APIs, so the OS runs the matching and the lockout. A successful match releases the wrapped data key, and the app never stores fingerprints or faces.

Biometrics break in ordinary ways: a new fingerprint gets enrolled, the sensor fails, the device passcode is removed. Each case falls back to the PIN, and both paths arrive at the same key. We do not use the device passcode as the vault fallback, because a phone handed over unlocked would then open the vault.

When the PIN is forgotten

If the file key exists only in a form wrapped by the PIN, no support engineer and no server can recover the vault, and that property is the reason the encryption is worth having. We offer three routes and let the product owner pick one:

A recovery wrap, where a security question or phrase holds a second copy of the data key, which is the model in our own iOS app.
A recovery file, exported once at setup and kept by the user.
Reset only, where the app says at setup that a forgotten PIN means the content is gone.

We do not build a support backdoor that decrypts a user's vault on request, because such a key would open every customer's vault at once.

Screenshots, app switchers, and side channels

On Android we set FLAG_SECURE on vault screens, which blocks screenshots and screen recording and blanks the thumbnail in the recents list. On iOS we blur the interface when the app leaves the foreground, so the switcher shows a cover, and we detect screen recording where the platform reports it.

The quieter leaks get closed too. Decrypted thumbnails never reach the system gallery, file names stay out of the media store, the clipboard clears on a timer, and PIN fields disable keyboard prediction. The cover has to hold at every entry point, including the icon and the notification text.

Encrypted export and backup

Vault content is excluded from iCloud and Google automatic backup by default, using the no-backup directories both platforms provide. Users can export on purpose, and we package the vault into a single encrypted archive with its own passphrase, so a copy on a laptop or another cloud account stays unreadable there.

How the engagement runs

The first phase is a data and threat model. We list what the app stores, who could plausibly get hold of the device, and which recovery route the product will offer.

The build follows in stages: unlock and key management, the encrypted storage layer, the viewer and import paths, then the cover interface and the platform protections. For a team adding a vault to an existing app, this is a module rather than a new product.

Testing runs on real devices, including a rooted Android build and a jailbroken iOS build, so the protections meet something closer to a hostile handset than a simulator.

What it costs

Vault work is billed at our flat rate of $39 per hour, and the phases above describe the scope better than an invented total. A standalone privacy utility usually lands inside the mobile app MVP order published on our pricing page: $4,800 to $8,500 across four to six weeks for a complete app with a cloud backend and store submission. A vault module added to an app you already ship is smaller, often a few weeks.

A vault with sharing, multi-device sync, or a paid subscription layer fits a monthly capacity plan from $2,699. The same pricing page lists both models and the full set of typical orders.

Proof

CalculatorX (HideX) is a native Swift iOS app where the vault sits behind a calculator-style interface: the user types a PIN and presses the equals key to get in. It stores photos, videos, and contacts, offers a decoy vault with its own password, and states that hidden files stay on the device. It proves the disguise and recovery model this service is built around.

Calculator Lock is the Android counterpart, hiding photos, videos, apps, and files behind a calculator icon, with fingerprint unlock, a decoy vault, and intrusion monitoring that photographs someone who fails the unlock. It proves the biometric path, the break-in alerting, and the media vault on Android.

Camera Filters is a native iOS photo editor with real-time filter previews, brightness and contrast controls, and cropping. It proves the media pipeline a vault viewer depends on.

Related services

Mobile app security audit and hardening for testing the finished vault against a hostile device
Mobile app development for the wider build the vault sits inside
Native iOS app development for Keychain and platform-level protections on iPhone and iPad
Mobile app privacy compliance for store labels that match a local-only storage claim
Camera and image utility app development for products where the vault sits beside capture and gallery features

Next step

Send us what the app will store, the platform you are targeting, and how the user should recover access if the PIN is forgotten. We will say which parts of the threat model the vault can answer and which belong to the device.

Contact us with the product idea or the existing app, or run the scope through the Vasilkoff.info estimator for a first estimate.