App Lock for iPhone — What iOS Offers, What It Misses, and What Actually Works

TL;DR

iOS 18 added per-app Face ID locking, but it only covers apps Apple chooses to expose and offers no protection against someone who knows the device passcode. Screen Time restrictions can block app categories but are trivial to bypass if the restriction passcode is weak or shared. Dedicated app-lock and vault applications fill the gap by encrypting files independently of the iOS sandbox, adding a second authentication layer that survives even if the phone itself is unlocked. For photos, messages, and documents that need real isolation, a vault app with its own key derivation and encryption is the only architecture that works.

What iOS Gives You Natively

Apple has slowly added app-level access controls, but each one serves a different purpose than what most people mean when they search for “app lock.”

Screen Time Restrictions

Screen Time, introduced in iOS 12, lets you set a four-digit passcode that blocks app categories, individual apps, or specific content ratings. It is the closest thing to a native app lock for iPhone, and it is the tool most parents reach for first.

The problem is architectural. Screen Time restrictions live inside the iOS configuration profile. Anyone who knows the device passcode can navigate to Settings > Screen Time and either disable restrictions or reset the Screen Time passcode using the Apple ID. The restriction passcode is a convenience gate, not a cryptographic boundary.

Screen Time works well for its intended use case — limiting a child’s screen time or blocking in-app purchases. It does not work for protecting sensitive files from an adult who has the device in hand.

iOS 18 Per-App Face ID

iOS 18 added a per-app Face ID toggle. In Settings > Face ID & Passcode, a new “Lock & Hide Apps” section lets you require Face ID before specific apps open. Apple exposes this toggle only for apps that adopt the NSFaceIDUsageDescription API — currently a short list that includes Notes, Messages, and a handful of system apps.

The limitation is twofold. First, most third-party apps — banking, email, photo vaults — do not appear in this list. Second, Face ID is a convenience layer, not a security boundary. If an attacker knows the device passcode, they can reset Face ID in Settings and access every app on the phone. The per-app toggle adds friction for a casual snooper, not protection against a determined one.

The Hidden Album and Locked Notes

iOS 18 also added Face ID gating for the Hidden album in Photos and for locked Notes. These are welcome additions, but they share the same weakness: the encryption key is tied to the device passcode. The Hidden album does not create a separate cryptographic container — it merely hides thumbnails behind a biometric gate. Forensic tools that bypass the lock screen can still extract the underlying files.

Locked Notes are better. Apple encrypts locked notes with a key derived from the note-specific password (or the device passcode if none is set). But the Notes app is not designed as a general-purpose file vault. You cannot store PDFs, videos, or arbitrary file types there.

What Native iOS App Lock Cannot Do

The gaps are specific and consistent:

No per-app password for arbitrary apps. Apple does not expose an API that lets any app be gated behind a custom password or pattern. If the app you want to protect is not on the iOS 18 Face ID list, the native tools cannot help.

No cryptographic separation from the device passcode. Every native iOS protection — Screen Time, Face ID, the Hidden album — ultimately derives its security from the device passcode. If someone knows that passcode, every native lock can be reset or bypassed.

No protection during device handover. When you hand your unlocked iPhone to someone — a colleague, a child, a border officer — native locks do not prevent them from opening apps that are not on the Face ID list. The device is unlocked; the apps are accessible.

No hidden or disguised vault. iOS has no mechanism for an app to present itself as one thing (a calculator, a utility) while functioning as something else (an encrypted file vault). Apple’s sandbox model assumes every app is what its label says.

These are not oversights. Apple’s threat model for iOS assumes the device passcode is the root of trust. Everything else is a convenience layer on top of that assumption. When your threat model includes someone who knows or can obtain the device passcode, the native layers are not enough.

Dedicated App-Lock and Vault Apps

Third-party app-lock tools for iPhone fall into two categories, and the distinction matters.

Category 1: App Wrappers and Configuration Profiles

Some “app lock” apps on the App Store work by installing a configuration profile or by wrapping web views around content. These apps do not encrypt files independently. They rely on the same iOS sandbox and device passcode that native tools use.

The practical effect is a second passcode prompt that looks like added security but does not add cryptographic separation. If the device passcode is known, the wrapper can usually be removed or bypassed. These apps are marginally better than nothing for casual privacy but offer no real protection against a knowledgeable attacker.

Category 2: Encrypted Vault Apps

A vault app creates its own encrypted container — a file system within the app’s sandbox that is sealed with a key derived from the user’s password or pattern, not from the device passcode. The files inside this container are encrypted with a cipher like AES-256-GCM, and the decryption key exists only in memory after successful authentication.

This architecture means the vault remains sealed even if the device is unlocked, even if the attacker knows the device passcode, and even if the phone is connected to a forensic tool. The vault’s security is independent of iOS’s security.

AppVault is built on this model. Files are encrypted with AES-256-GCM using a unique 96-bit nonce per file, with keys derived through PBKDF2-SHA256 at 600,000 iterations and wrapped by a key generated inside the iPhone Secure Enclave. The Enclave key never leaves the chip. Apple’s Platform Security guide documents this hardware boundary. The OWASP Password Storage Cheat Sheet recommends 600,000 PBKDF2 iterations for SHA-256 as of 2026.

Because the vault’s key derivation is independent of the device passcode, knowing the iPhone passcode does not help an attacker open the vault. The two authentication systems — device and vault — are mathematically separate.

When You Need a Vault App vs. Native Tools

The decision comes down to the threat model.

Use Screen Time if: you are a parent setting limits for a child, or you want to block yourself from impulse-opening social media. Screen Time is sufficient for behavioral nudges.

Use iOS 18 per-app Face ID if: you want to add a biometric gate to Notes or Messages and you trust that no one else knows your device passcode. It is a convenience feature, not a security boundary.

Use a vault app if: you store photos, documents, or messages that must remain private even if the device is unlocked or the passcode is compromised. This includes journalists protecting sources, lawyers storing privileged communications, medical professionals with patient data, or anyone handing their phone to a border officer, a repair technician, or a curious colleague.

Use a vault app with a disguised icon if: you need the vault itself to be invisible on the home screen. AppVault’s Calculator Launcher ships a fully functional iOS calculator — it performs standard arithmetic, handles order of operations, and shows a history tape. A long-press on the equals key opens the encrypted vault. This is not a “fake calculator.” It is a real calculator with an opt-in shortcut, built to satisfy Apple guideline 4.3 (alternate icons).

What to Look for in an App-Lock Download

The App Store has hundreds of apps with “app lock” or “applock” in the name. Most of them are low-effort wrappers with ad SDKs and no independent encryption. Before downloading any app-lock application for iPhone, check these criteria:

Independent key derivation. The app should derive its encryption key from your password or pattern using a function like PBKDF2, Argon2, or scrypt — not from the device passcode. If the app’s security collapses when the device passcode is known, it is not a real vault.

Published cipher and mode. Look for AES-256-GCM or ChaCha20-Poly1305. If the app does not name its cipher, assume it is using something weak or homemade.

No network calls. A vault app that phones home is a vault app that can be compelled to hand over data. AppVault makes zero network calls by default. There is no account, no telemetry, no third-party SDKs.

No password reset. This sounds counterintuitive, but a vault app that can reset your password is a vault app that can be socially engineered. If you forget the pattern, the vault stays sealed. AppVault generates an optional written recovery passphrase during setup — write it down and store it separately.

Transparent threat model. The app should tell you what it defends against and what it does not. AppVault’s threat model page lists specific attack scenarios — customs inspection, shared device, lent phone, forensic extraction — and is honest about the limits of any software-only solution on a platform Apple controls.

The Gallery Lock Question

“Gallery lock” is one of the most-searched terms in this space. It refers to the ability to lock the iPhone’s photo gallery behind a separate password or biometric gate. Apple does not offer this natively — the Hidden album is the closest equivalent, and it is not cryptographically independent.

A vault app solves this by moving photos out of the camera roll entirely. When you import a photo into AppVault, the original is deleted from the Photos app and stored only inside the encrypted container. The photo no longer appears in the camera roll, in search, in Siri suggestions, or in iCloud Photos. It exists only behind the vault’s authentication layer.

This is the only way to achieve true gallery lock on iPhone. Hiding photos in the Hidden album is not enough. Deleting them and relying on the Recently Deleted folder is not enough. The files must be encrypted with a key that the device passcode cannot derive.

Fingerprint, Face, and Pattern — Which Authentication Is Best?

App-lock apps on iPhone typically offer three authentication methods:

Face ID / Touch ID. Convenient, but the biometric template is stored in the Secure Enclave and gated by the device passcode. If the device passcode is compromised, the biometric gate can be reset. Use biometrics as a convenience layer, not as the sole security mechanism.

PIN or password. A numeric PIN has limited entropy — a four-digit PIN has only 10,000 possible combinations. A six-digit PIN has one million. An alphanumeric password is stronger but slower to enter on a mobile keyboard.

Pattern lock. AppVault uses a 5×5 grid pattern. The number of valid patterns on a 5×5 grid exceeds 7.6 million for patterns of length 5 or more, and the effective entropy increases with pattern complexity. The pattern is not stored — it is fed into PBKDF2-SHA256 with a per-install 128-bit salt, producing a 256-bit key that wraps the vault’s master key.

The strongest approach combines a pattern or password with biometric convenience. AppVault requires the pattern to unlock the vault; Face ID can be enabled as a shortcut after the first successful pattern entry. If Face ID fails or is disabled, the pattern still works.

What AppVault Does Differently

Most app-lock apps on the iPhone are frontends for the iOS keychain or simple file obfuscation. AppVault is built around a zero-knowledge architecture — the developer cannot access your files, your pattern, or your encryption keys. There are no servers to subpoena, no account database to breach, no telemetry to leak.

The cryptography stack is published and cited. AES-256-GCM with a unique 96-bit nonce per file (NIST FIPS 197, RFC 5116). PBKDF2-SHA256 at 600,000 iterations with a per-install 128-bit salt (OWASP 2026). Secure Enclave wrapping so the derived key never exists in application memory in plaintext (Apple Platform Security guide).

The catalog itself is encrypted. An attacker with raw access to the app’s sandbox cannot tell how many files exist, what their names are, or when they were added. The vault is opaque from the outside.

For the full feature-by-feature breakdown against the closest competitors, see the comparisons with Vaultaire and Keepsafe.

Sources

• Apple Support: Hide and show photos on iPhone
• Apple Support: Use Screen Time on iPhone
• Apple Platform Security guide: Data protection overview
• Apple Developer: App Privacy details on the App Store
• NIST FIPS 197: Advanced Encryption Standard