App-level encryption complements iOS Data Protection by keeping sensitive data sealed at the moments the operating system leaves it readable. iOS encrypts every file with keys tied to the device and passcode, but most app data stays accessible once the phone has been unlocked, and anything running with the app’s privileges, or on a jailbroken device, can read it. Otukan adds encryption the app controls for the files, database records and preferences you mark as sensitive. Keys stay in the Keychain on that device only and are released while jailbreak and hooking checks are clean. This page covers iOS; Android has its own controls.
Storage scope
Not all app data sits in the same place, and each place is protected differently by iOS.
| Where data lives | What iOS provides | Remaining exposure | What Otukan adds |
|---|---|---|---|
| Files in the app container | File encryption by protection class; most apps default to a class readable after first unlock | Readable while the device is unlocked or by a process with the app’s access | Encryption of marked files with an app-held key |
| Local databases | The database file inherits its protection class | Records readable in the same conditions as any file | Encryption of sensitive records before they are written |
| Preferences and settings | Stored as ordinary files | Often overlooked, and frequently holds tokens or flags | Encryption of marked values |
| Keychain | Encrypted items with accessibility rules you choose | Items can be read on a jailbroken device if access is not gated | Release of Otukan keys tied to runtime checks |
| Caches and temporary files | Same file protection as other files | System and library caches may hold copies of sensitive responses | Review of cache paths during onboarding |
The choice of what to protect starts with your data, not with our tooling. During onboarding we map every place your app, its libraries and its extensions write data. For Swift and Objective-C apps, the details are on iOS app security and Swift app security.
Key handling
Encryption is only as good as the handling of its keys. Responsibility is split clearly.
| Responsibility | Handled by |
|---|---|
| Device-level file and Keychain encryption | iOS |
| Hardware-held elliptic-curve keys, on devices with a Secure Enclave | iOS and the device |
| Creating and wrapping data keys, and deciding when to release them | Otukan, under your policy |
| Deciding which data is sensitive and when keys rotate | Your team, with our guidance |
| Server-held secrets and user re-provisioning | Your backend |
Otukan keeps data keys as this-device-only Keychain items and, where a Secure Enclave is available, protects them with a key that never leaves it. The code that handles keys is obfuscated, so it is hard to find and study. For secrets embedded in the app itself, see mobile app secrets protection.
Lifecycle
Data exposure changes with what the device and user are doing.
Unlock states
Before the first unlock after a restart, most app files are unreadable even to the app. After it, they stay readable until the device restarts. Otukan’s own layer does not depend on the lock state: a marked record is decrypted only when the app needs it and only while checks pass.
Backups and new devices
App files are included in device backups unless the app excludes them. Because Otukan’s keys are this-device-only, a backup restored to another phone holds ciphertext without a key. The app then starts fresh and re-syncs from your server, a journey we design and test with you.
Updates and key rotation
An app update keeps the same Keychain items, so protected data remains readable after an update from the App Store. When you rotate a data key, Otukan re-encrypts marked records under the new key the next time the app opens them, and the old key is then removed.
Runtime exposure
While the app is using data, it is decrypted in memory. Otukan shortens how long it stays there, and hooking detection watches for tools that read it. Healthcare and workforce teams will find sector context on healthcare mobile app security and enterprise mobile app security.
Each control is verified on signed builds: protected data is read in an authorised lab under a jailbreak to confirm key release is withheld, the same journey runs on a clean device to confirm it works, and install, update, restore and sign-in are repeated, with versions, devices and the reviewer recorded.