Otukan detects a debugger attached to the build you publish, and leaves your own engineers free to debug everything else. On Android, separate checks cover the Java debugging interface and native tracers; on iOS, a dedicated check spots a debugger attached to the app process. Enforcement follows the build type: development and QA builds stay debuggable or simply observe, while the store build applies the response you choose per flow and sends the signal to your backend. Anti-debugging makes stepping through your logic slower and louder. It works best alongside hooking, emulator and integrity checks.
Why debuggers matter on a release build
A debugger is the most direct way to learn how an app makes decisions. With one attached, an analyst can pause the app at a licence check, read a session token the moment it is decrypted, change a return value so a risk rule passes, or watch exactly which fields a payment request carries. Obfuscation makes the code harder to read, but a debugger lets someone skip reading and simply watch. That is why debugger detection belongs in any runtime protection plan for apps that handle money, identity or valuable logic.
Legitimate debugging, on the other hand, is part of daily engineering. The goal is not to make debugging impossible everywhere; it is to make the build your users install hostile to it, and to tell your backend when someone tries.
Detection scope by platform
A debugger reaches a mobile app through different doors on each platform, and Otukan builds a separate check for each door. Nothing on this page carries an Android behaviour across to iOS, or the reverse.
| Route | Platform | What an analyst gains | What Otukan checks |
|---|---|---|---|
| Java debugging interface | Android | Breakpoints and variable inspection in Kotlin and Java code | Whether the interface is active for your process or was enabled by a rebuild |
| Native tracing | Android | Step-through of compiled libraries, including engine code under Flutter and React Native | Whether another process is tracing your app’s native code |
| Debugger attachment | iOS | Control over the running process and its memory | Whether a debugger is attached to the app process |
| Rebuilt debuggable copy | Android and iOS | A release altered and re-signed so a debugger can attach | Integrity and signing identity against your release |
Android: two layers
Android apps run managed code and often native libraries side by side. A debugger on the managed layer sees your Kotlin or Java logic; a tracer on the native layer sees compiled libraries, encryption routines and framework engines. Otukan watches both, because protecting only one leaves the other as the easy path.
iOS: a narrower door
An App Store build is not normally open to a debugger, so attachment on a store build usually means the device is jailbroken or the app has been re-signed. Otukan reports the attachment and your backend can weigh it with the signing details that come with it. For jailbreak signals, see iOS jailbreak detection.
Build modes
Anti-debugging fails when it gets in the way of your team. Otukan starts from the build you are shipping and sets enforcement to match.
| Build | Who uses it | Debugging | Otukan policy |
|---|---|---|---|
| Development | Engineers at their desks | Expected | Checks off or observe only |
| QA and pre-release | Testers and automation | Sometimes needed | Observe and report, so testers see what would fire |
| Store release | Your users | Never expected | The response you set for each flow |
Keeping these policies separate means a tester who attaches a debugger to chase a bug is not locked out, while the same action against the store build produces a signal your server can act on.
User impact and diagnostics
Response choices
Otukan gives each flow its own response. Browsing a catalogue under a debugger may only need a recorded signal. Signing in, changing account details or approving a payment can be restricted or closed. Start in observe, measure, then tighten one flow at a time. Policy design is covered on threat response.
Handling diagnostics
Each detection names the condition, the build, the platform and the flow. You choose whether any further fields go with it. That keeps the signal useful to analysts without sending personal data from the device.
Proving the check
Before a protected release ships, your engineers and Otukan attach a debugger to the protected build in an authorised lab and confirm the signal. The same journey then runs on a legitimate device, which should stay quiet. Finally, install, update, sign-in and your most sensitive flow are repeated, and the results are recorded with devices, OS versions and the reviewer.
Anti-debugging sits inside Otukan’s wider runtime protection, which is covered on mobile RASP. For the full product, return to mobile app security.