Otukan fits within the three boundaries Apple sets for every iOS app: how it is built into signed binaries, how Apple signs and delivers it, and what the sandbox lets an app see while it runs. It protects your Swift and Objective-C code, embedded frameworks and app extensions, binds its integrity checks to properties that survive Apple’s re-signing, and leaves your certificates with your team. At runtime it detects jailbreaks, hooking, swizzling and tampering, and sends each signal to your backend with the requests that matter. Every control is built and validated for iOS on its own terms. Android has its own page, Android app security.
Inputs Otukan protects: code, frameworks and extensions
An iOS app is a bundle of several signed binaries, not one. Otukan protects each binary you choose and keeps your debugging workflow intact.
| Input | What it is | How Otukan handles it |
|---|---|---|
| Swift code | Compiled to machine code, but type metadata and symbol names can remain readable | Hardens readable symbols and strings in the release binary |
| Objective-C code | The runtime keeps class names, selectors and method lists, which also makes method swizzling easy | Protects sensitive classes and detects swizzling of their methods at runtime |
| Embedded frameworks | Dynamic frameworks and XCFrameworks are separate binaries; static libraries and Swift packages are linked into the main executable | Protects your own frameworks and lets you decide how vendor frameworks are treated |
| App extensions | Widgets, notification service, share and keyboard extensions are separate executables with their own entitlements and memory limits | Covers the extensions you choose, within each extension’s memory limit |
| Cross-platform frameworks | Flutter ships compiled Dart in App.framework; React Native ships a JavaScript or Hermes bytecode bundle | Protects the framework’s own code, not only the native shell |
| Debug symbols | Crash reports are symbolicated with dSYM files whose UUIDs must match the shipped binary | Keeps your crash reports readable with the matching dSYMs |
| Deployment target | The minimum iOS version decides which APIs, such as App Attest, are available | Validates each control per iOS version on physical devices |
Framework-specific detail is on Flutter app security and React Native app security, with hybrid apps on Ionic and Cordova app security.
Physical devices and the simulator
The simulator runs a separate build compiled for your Mac, not the device binary you ship. App Attest is not available there, and the simulator does not enforce device code signing the way an iPhone does. Otukan validates protection behaviour on physical iPhones and iPads, where your users run your app.
Distribution
Signing authority
Every iOS app is signed with a certificate issued by Apple, and each app extension and embedded framework carries its own signature. Because Apple processes App Store builds, the binary on a user’s device is not byte-identical to the archive you uploaded. Otukan’s integrity checks rely on properties that survive that processing, so they hold across the distribution paths you use:
| Path | Who signs what users install | How Otukan handles it |
|---|---|---|
| App Store | Apple re-signs the app and encrypts it with FairPlay | Checks bound to properties such as team ID and bundle ID |
| TestFlight | Apple, as for the App Store | Verified separately, because receipts and some environment values differ from App Store installs |
| In-house (Apple Developer Enterprise Program) | Your enterprise distribution certificate, for internal use only | Checks bound to your enterprise identity and validated through certificate renewal |
| Custom apps through Apple Business Manager | Apple, through the App Store | Handled as the App Store path |
| Alternative distribution in the EU | Apple notarises and signs; a marketplace or your website delivers | Each channel verified separately |
Signing certificates and provisioning profiles stay with your team; Otukan does not need them.
Protected-build testing
Otukan works with your team on a test plan for the build Apple delivers, not only the archive:
- a TestFlight install and an update from the previous App Store version
- sign-in, Keychain access and your most sensitive flows, such as payments or account changes
- each app extension, including under its memory limit
- a crash in the protected build, to confirm it symbolicates with the matching dSYM
- the same journeys on several iPhone and iPad models and iOS versions
Detect and prevent: how Otukan works within iOS
The iOS sandbox protects apps from each other, and it also limits what an app can stop inside its own process. Some actions iOS prevents itself. For the rest, Otukan detects the threat and hands the decision to your policy and your server.
| Control | Detect or prevent | What Otukan does |
|---|---|---|
| Jailbreak detection | Detect | Combines independent signals of a modified system and reports them to your policy |
| Debugger attachment | iOS prevents it on stock devices for release builds without the get-task-allow entitlement; detect otherwise | Detects attached debuggers and responds per flow |
| Hooking and swizzling | Detect | Detects changed method implementations and injected libraries at runtime |
| Re-signing and tampering | Detect | Compares code signature and bundle properties with expected values |
| App attestation | Your server decides | Gives your server evidence of a genuine app instance, using App Attest where available |
| Screen capture | Detect; sensitive views can be hidden during recording | Hides sensitive views while recording or mirroring, and reports screenshots |
| Data at rest | iOS prevents access while locked, when the right Data Protection class is used | Keychain and Data Protection remain the foundation Otukan builds on |
Further iOS controls have their own pages: network security, memory protection, secrets protection, code obfuscation and app shielding. Implementation guides are collected under iOS app security guides.
Detection pays off in the response. Otukan sends its signals with login and payment requests, so your backend can refuse a risky session rather than trusting the device alone. Code obfuscation and runtime protection (RASP) make removing those checks slower and costlier, and attempts to remove them leave a signal for your security team.
For how iOS fits the wider protection model, return to mobile app security. If your iOS app is already on the App Store, a free App Exposure Check reviews the public store release.