Otukan iOS RASP lets your app notice hostile conditions while it runs and act on them before a sensitive action completes. It detects jailbroken devices, attached debuggers, dynamic instrumentation, libraries injected into the process, and sessions on the simulator or a Mac. Each condition feeds a response you set per flow, from observe to terminate, and a signal your server can weigh. Scope is the running iOS app on physical iPhones and iPads; RASP raises the cost of analysis and abuse rather than ending it, so the backend keeps the final decision.
How runtime self-protection works across Android, iOS and cross-platform apps is covered on mobile RASP.
iOS event coverage and detection timing
A check is only useful if it runs when the risk is real. Otukan places its checks at the points in the iOS app lifecycle where an attacker is most likely to act.
| Moment | Why it matters on iOS | What Otukan checks |
|---|---|---|
| Launch | Injected libraries and tweaks load with the app | Loaded images, jailbreak traces, run environment |
| Return from background | A debugger or instrumentation tool can attach while the app is suspended | Debugger state, instrumentation artefacts |
| Before a sensitive flow | Sign-in, payment and profile changes are what an attacker wants | A fresh evaluation of every active condition |
| During the flow | Hooks can be installed after launch | Rewritten entry points in the functions you protect |
The checks run in your app’s own process, so they apply whether the screens are written in Swift, Objective-C, Flutter or React Native. Your server also learns which moment produced each signal, which separates a device that arrived compromised from one that changed mid-session.
What each condition means
- Jailbreak. The sandbox and code-signing rules iOS relies on are weakened. Modern jailbreaks are often rootless and leave the system volume untouched, so Otukan’s checks look beyond file paths.
- Debugger. Someone is stepping through your distribution build, which normally never runs under a debugger.
- Instrumentation and hooks. A tool is rewriting your functions in memory to read arguments or change return values. Hooking detail is covered on iOS hooking detection.
- Environment. The simulator exists only for development, so a customer session there deserves scrutiny. An iPhone app on an Apple silicon Mac can be a real customer if you allow Mac availability, so Otukan reports it as its own environment and your policy decides.
Response choices during sensitive flows
A signal is information. The response is a product decision, and Otukan lets you make it per flow instead of once for the whole app.
- Observe. Report the condition and change nothing for the user. The right start for any new check.
- Warn. Tell the user the device looks unsafe and let them continue with low-risk actions.
- Restrict. Block the flow in progress, or require step-up authentication, while the rest of the app works.
- Terminate. End the session when the condition makes any further action untrustworthy.
The strongest pattern keeps enforcement on your server. The app sends Otukan’s signal with the sign-in or transaction request, your backend combines it with App Attest and its own risk rules, and a refusal happens where the attacker cannot patch it out. Attestation detail is covered on iOS app attestation.
Version updates and legitimate-user recovery
When iOS or your app changes
Each iOS release moves system paths, loader behaviour and sandbox rules, and jailbreak tools adapt in turn. Otukan tests its checks against new iOS releases and ships updated detection in your next protected build. Your own releases matter too: a new SDK or framework can add loaded libraries the check has not seen, so each release is accepted again before it ships.
Keeping real users whole
A false alarm on a real customer is a support ticket and a lost transaction. Otukan is designed so that a false alarm on a real customer has a way back:
- Start each check in observe mode and read its rate per device model and iOS version.
- Enforce only in the flows that need it, and only once the data supports it.
- Show a message that says what to do next, with a reference your support team can look up.
- Relax policy on the server for a model, version or user while you investigate.
Proving each check before release
Every control is accepted with your engineers on physical devices: reproduce the condition in an authorised lab, repeat the same journey on a clean supported device, then run install, update, sign-in and your most sensitive flow. Versions, results and the reviewer are recorded for each release. Release practice is covered on iOS app security guides.
The wider iOS picture is covered on iOS app security. Already live on the App Store? Ask for a free App Exposure Check of that version.