iOS has a reputation for being "the secure one" — and for the most part, it earns it. But security isn't magic. It's a stack of well-designed layers, each with a specific job. This article breaks down what those layers are, where they matter in the real world, and what you as a developer actually need to care about.
Apple's approach is defense in depth. From the moment you hit the power button, a chain of trust kicks in — the Boot ROM checks the bootloader, the bootloader checks the kernel, the kernel checks the system. If anything in that chain fails verification, the device stops cold. That's why persistent firmware-level malware basically doesn't exist on iOS without a hardware-level exploit.
On top of that, every app runs in its own sandbox. It can't touch another app's files, can't access hardware without permission, and can't run unsigned code. The OS enforces this at the kernel level — not just in software — so a compromised app can't quietly go rogue.
This is the crown jewel. It's a dedicated coprocessor, completely isolated from the main CPU, that handles all cryptographic operations — key generation, biometric data, payment credentials. The kicker: even if the main OS is compromised, the Secure Enclave stays walled off. It processes your Face ID scan and returns a yes/no without ever handing the raw biometric data to the app or the OS.
Every iOS app lives in its own container. It can't read files from other apps, can't spawn arbitrary processes, and can't access system resources without explicit entitlements granted by Apple at review time. If you need to share data between apps, you use App Groups — and you have to declare that upfront.
The right place to store anything sensitive: tokens, passwords, private keys, certificates. Keychain data is encrypted and hardware-backed. It survives app reinstalls, respects device lock state, and — critically — doesn't show up in iCloud backups unless you explicitly allow it. If you're storing auth tokens anywhere else, you're doing it wrong.
Files on iOS aren't just "encrypted or not". There are four protection classes that control when the decryption keys are available:
| Class | Keys available when... |
|---|---|
completeUnlessOpen |
App is open, even if device is locked |
complete |
Device is unlocked only |
completedUnlessUntilFirstUserAuthentication |
After first unlock since boot |
none |
Always (no protection) |
For anything sensitive, you want .complete or .completeUnlessOpen.
Every binary on iOS must be signed by a developer identity that Apple has verified. Unsigned code won't run, period. Tampered binaries fail signature validation. This is what makes iOS so hostile to sideloaded malware compared to other platforms.