An iOS app can tell it is running on a jailbroken device when several independent signs agree, and Otukan is built to read those signs. Apple provides no public jailbreak API, so Otukan’s local checks look for the side effects a jailbreak leaves: files the app should not see, sandbox rules that no longer hold, and code in the app’s process that you did not ship. Because the checks are independent, a hiding tweak has to defeat several of them at once. Your server can pair the signal with App Attest and apply the response you set per flow. This page covers iOS; Android root detection is its own control.
The broader set of runtime checks is covered on mobile RASP.
Detection boundary
Two kinds of evidence exist on iOS. They answer different questions, and Otukan uses each for what it proves.
Local checks
These run inside your app and look for the side effects of a jailbreak.
- Filesystem traces. Package manager apps, tweak directories and binaries that jailbreaks install. Rootless jailbreaks keep the system volume unchanged and place their files elsewhere, and Otukan covers both layouts.
- Sandbox integrity. Attempts to write outside the app’s container or call functions the sandbox normally blocks. Success shows the sandbox has been weakened.
- Loaded code. Dynamic libraries in the app’s process that were not part of your build, which is how most tweaks and hooking tools work.
- URL schemes. Whether a package manager’s URL scheme can be opened. This needs the scheme declared in
LSApplicationQueriesSchemes, and it adds one more independent sign.
Platform-provided evidence
App Attest generates a key in the Secure Enclave and lets your server verify that requests come from a genuine instance of your app, identified by your team ID and bundle identifier. DeviceCheck lets your server store two bits per device. Neither reports jailbreak state; together with Otukan’s local checks they give your server both halves of the picture.
| Evidence | Where it is evaluated | What it shows |
|---|---|---|
| Otukan local checks | In the app, reported to your server | Jailbreak side effects on this device, by check |
| App Attest | On your server | The request comes from your genuine app |
| DeviceCheck | On your server | Per-device state your server set earlier |
Supported versions
OS-dependent behaviour
Jailbreak techniques are tied to iOS versions and chips, and they change with each release. File locations, sandbox behaviour and the libraries a jailbreak injects all differ between versions. Some older chips have a bootrom weakness that a software update cannot patch, so those devices stay exposed across iOS updates. Otukan keeps its checks current as new iOS versions and jailbreaks appear, and each check carries its own tested iOS version range, which we share in a technical session.
Build and distribution
Checks behave differently depending on how the app is built and shipped. An Objective-C method can be swapped at runtime, so Otukan does not rely on a single method a tweak can replace. Swift, Objective-C, Flutter and React Native apps all get the same checks, and the result reaches your policy directly. Development, TestFlight, enterprise and App Store builds carry different entitlements and signing, and app extensions run in their own, more limited process. Otukan documents how each check behaves in each of these.
Staying current
Every Otukan check is proven on signed builds running on physical devices, and retested on each new iOS version. iOS-specific guidance is covered on iOS app security.
Response policy
Continuity for legitimate users
Otukan reports which check fired and lets you start in observe mode. An unusual reading on a legitimate device then affects one flow, not the whole app, and your team sees exactly why.
Choosing a response per flow
| Flow | Recommended starting response | Why |
|---|---|---|
| Browsing and public content | Observe and record | A jailbreak changes little about the risk here |
| Login | Send the signal with the request; decide on the server | The backend combines it with App Attest and account context |
| Keychain-stored secrets | Limit what is stored locally | A jailbreak can expose app data and Keychain items |
| Payments and account changes | Step up or refuse, based on combined signals | The cost of a wrong decision is highest |
Measure how often each check fires on real users, then tighten flow by flow. Policy design for runtime signals is covered on threat response.
Proving each check
Before your protected release ships, Otukan proves each check with your team:
- Reproduce a jailbreak in an authorised lab and confirm the expected signal.
- Run the same journey on a legitimate, supported device and confirm the check stays quiet.
- Repeat install, update, login and your most sensitive flow on the signed build.
Results are recorded with devices, iOS versions and the reviewer. For a structured way to evaluate options, see the iOS jailbreak detection solution guide.