Runtime interception in an iOS app shows up in four places: the loader, which reveals libraries that should not be there; the Objective-C runtime, where method implementations can be swapped; the first instructions of native and Swift functions, which can be patched to jump elsewhere; and symbol pointers, which can be rebound to replacement code. Otukan checks each of these independently inside your protected app, repeats the checks just before the functions you name as critical, and sends a signal your backend can act on. It makes interception slower to hide and costlier to sustain. For the cross-platform picture, see mobile app hooking detection.
Injected libraries and method interception
Most interception on iOS starts by getting foreign code into your process. On a jailbroken phone a tweak loader does it at launch. On a stock phone the attacker has to embed a library into a re-signed copy of your app.
What Otukan looks at
| Layer | What the attacker does | What Otukan checks |
|---|---|---|
| Loader | Adds a library to the process at launch or later | Loaded images against the expected set for your bundle and iOS |
| Objective-C runtime | Swaps the function behind a selector | Current implementations of sensitive selectors against your build |
| Function entry | Overwrites the first instructions to jump to new code | The opening bytes of each marked function |
| Symbol binding | Points a lazily bound call to a replacement | Where sensitive system and library calls actually resolve |
Each layer is independent. An attacker who hides a library from the loader list still leaves patched instructions or changed implementations for the other checks to find. For a PIN check, a signing routine or a transfer, Otukan runs the checks immediately before the call, not only at launch, because instrumentation often attaches once the app is already running.
Swift and Objective-C runtime differences
The language you wrote a function in changes how it can be hooked.
- Objective-C methods are dispatched by name through the runtime. Swapping one takes a single runtime call, so these are the most common target. Otukan compares implementations directly.
- Swift members exposed with
@objccan be swapped in the runtime, which changes what every Objective-C caller reaches. Members marked@objc dynamicare always dispatched by message, so a swap reaches Swift callers too. Otukan treats both like Objective-C methods. - Pure Swift functions are called directly or through type tables. Intercepting them means patching the function entry or its call sites, which Otukan’s entry checks cover for the functions you mark.
- C and system calls go through symbol stubs. Rebinding a stub is how attackers fake a system answer, such as a clean file check; Otukan confirms those calls resolve where iOS placed them.
This is why Otukan asks which language each critical function uses: the right check depends on it. The Objective-C side is expanded on Objective-C app security, and Swift on Swift app security.
What your backend receives
Each hooking signal carries the layer that fired, the function, selector, library or symbol involved, and the moment it was seen: at launch, at sign-in or immediately before a named call. Your security team can group sessions by technique, notice a new tool spreading across accounts and tighten the server-side decision for one flow while the app itself stays unchanged. When a device that normally reports stops sending signals altogether, your server can treat that silence as a risk too.
Clean-device and authorised-instrumentation tests
A hooking check is only trustworthy when it fires under attack and stays silent for real customers. Otukan accepts every protected release with both.
Positive tests
In an authorised lab, your engineers and Otukan hook each named function with dynamic instrumentation on a jailbroken test phone, and separately embed a library into a re-signed test copy. Each technique must produce its expected signal, name the right function and trigger the response set for that flow.
Negative tests
The same journeys run on stock, non-jailbroken iPhones with the distribution-signed build. Approved SDK swaps must stay silent, and install, update, sign-in and your most sensitive flow must behave exactly as in the unprotected build.
Recording
Each run records the iOS version, device model, build, expected and actual signals, and the reviewer. That record becomes your baseline for the next release. For the full runtime layer, see iOS RASP, and return to iOS app security for the platform overview. More material is in iOS app security guides.