Otukan tells your app and backend whether it is still the build you shipped. It answers four questions inside the running app: is this your release, has anything been injected, is anyone instrumenting it, and is the operating system underneath still intact? It detects repackaged and re-signed copies, hooking frameworks, injected code, debuggers and rooted or jailbroken devices, then responds per flow and reports the result to your backend. Evaluate it with those four questions on your own test devices. Integrity evidence makes tampering slower and visible, and pairs with platform attestation on your server. Otukan covers Android, iOS, Flutter and React Native apps, scoping each check per platform.
What is at stake
Almost every other control in a mobile app assumes the app itself is intact. A fraud signal, a biometric result or a screen-capture rule means nothing if an attacker has rewritten the code that produces it. Integrity is the foundation the rest of your protection stands on.
Affected flows
The damage shows up in the flows that matter most. A repackaged banking app harvests credentials from people who downloaded it from an unofficial source. A hooked payment flow returns “approved” without a real check. A patched subscription app unlocks paid features for free. A rooted device lets malware read data the sandbox was meant to protect.
The trust boundary
The boundary sits between your release and everything that happens to it after it leaves the store. Your signing certificate marks the start. From that point on, Otukan watches for the changes that break the chain: a new signature, altered files, foreign code in the process, a debugger attached, or an operating system that no longer enforces its own rules.
| Question | What breaks it | Otukan control |
|---|---|---|
| Is this my build? | Repackaging, re-signing, sideloading | Repackaging and re-signing detection, anti-tampering |
| Is anything injected? | Foreign libraries, patched code | Code injection prevention |
| Is anyone instrumenting it? | Hooking frameworks, debuggers | Hooking framework detection, anti-debugging |
| Is the OS intact? | Root, jailbreak, modified system | OS integrity signals |
Where integrity is enforced
The app
Only code inside the app can see its own process in real time. Otukan’s checks run there, at launch and throughout the session, and each flow reacts according to the response you set: observe, warn, restrict or terminate. For the runtime layer in detail, see mobile RASP.
The operating system
Each platform enforces code signing and sandboxing, and each offers attestation: Play Integrity on Android and App Attest on iOS. These are strong, but they depend on an intact system, and their verdicts are checked by your server rather than acted on inside the app. Root and jailbreak detection matter because they tell you when the platform’s own protections may no longer hold. Platform specifics are on Android root detection and iOS jailbreak detection.
The backend
A decision taken on the device can be undone by someone who controls the device. Otukan sends integrity results with sensitive requests, so your backend can refuse, step up or record them, and can combine them with platform attestation verdicts. For server-side verification, see app attestation.
How to evaluate application integrity
Checks per platform
Ask for each check to be documented per platform. Repackaging looks different on Android, where anyone can re-sign an APK, than on iOS, where re-signing needs a developer certificate and sideloading. Root and jailbreak are separate problems with separate signals. A single “integrity” label should expand into distinct Android and iOS lists.
A test pack you run
Build your own test pack. Re-sign a copy of your app with a different certificate and confirm it is recognised. Load an instrumentation framework on a test device and confirm the hook is detected before a sensitive result returns. Attach a debugger to a release build. Run the app on a rooted Android device and a jailbroken iOS device. For each test, check the in-app response and the record that reaches your backend.
Effect on genuine users
Integrity checks must leave genuine users alone. Measure how often root and jailbreak signals fire on your real audience before you enforce, because some legitimate users run modified devices without malice. Set a proportionate response per flow: a news screen can observe while a payment stops. Confirm start-up time on your target devices with the protected build. For a check of your current public release, request a free App Exposure Check.