Evaluate anti reverse engineering by first writing down what an analyst gains from your app, then deciding which layer defends each gain: the app, the operating system or your backend. Protection inside the app makes static reading and live analysis slower and costlier, and tells your backend when analysis is under way. The backend keeps the final decision and treats the app as untrusted. This guide helps a mobile security team compare solutions on Android and iOS against that model and test them on a real protected build. Obfuscation techniques in depth sit in a separate guide.
The Otukan control is covered on reverse engineering protection.
Threat and trust boundary
Reverse engineering is rarely the goal. It is the first step towards something else, so name the flow it leads to.
| What an analyst gains | Flow it enables | Where trust breaks |
|---|---|---|
| API paths, parameters and request signing logic | Scripted clients that imitate the app | Between app and backend |
| Business rules such as limits, fee rules or eligibility | Crafted requests that bend the rules | In the backend, if it trusts the client |
| Location of security checks | Patched or repackaged copies without them | In the app package |
| Embedded keys, tokens or endpoints | Direct abuse of third-party services | In the shipped binary |
| Proprietary algorithms | Cloned features or competing apps | Intellectual property, not a session |
- Which rows apply to your app, and which is the most expensive if it happens?
- Which flows would a scripted client or patched copy reach first?
- Which values in your app should not be there at all and belong on the server?
Control fit
No single layer defends every row. Assign each gain to the layer best placed to handle it.
What the app does
The app can make analysis harder to start and slower to finish. Static protections rename identifiers, hide strings, reshape control flow and protect native libraries, so a decompiler shows less meaning. Runtime protections detect debuggers, hooking and emulators, which are the tools of live analysis. Integrity checks catch the patched copy that analysis produces.
What the operating system does
Both platforms isolate apps in a sandbox. On Android, R8 shrinks and renames code when minification is enabled, but Kotlin and Java bytecode still decompiles to readable code. On iOS, App Store binaries are encrypted for distribution and decrypted on the device at launch; on a jailbroken device an analyst can capture the decrypted binary. These are useful baselines, not anti reverse engineering on their own.
What the backend does
The backend decides what a request is allowed to do, whatever the client claims. Secrets that grant access belong on the server. Attestation verified on your server shows whether a request came from your genuine app.
| Gain | App | Operating system | Backend |
|---|---|---|---|
| API contract | Obfuscation, string protection | Sandbox | Attestation, rate and rule checks |
| Security check location | Obfuscation, integrity checks | Store signing | Refuse unsigned or unattested calls |
| Live analysis | Debugger, hooking and emulator detection | Platform restrictions | Distrust flagged sessions |
| Embedded secrets | Protect what must ship | Android Keystore, iOS Keychain | Move the rest to the server |
How Otukan answers. Otukan covers the app column on Android and iOS: it obfuscates identifiers, strings and control flow, protects resources and native libraries, detects debuggers, hooking and emulators, and checks integrity. Runtime signals travel to your backend so the server can stop trusting a session under analysis. You choose which code gets the heaviest protection.
Evaluation
Measure each option on your own build, per platform.
Supported platforms
- Which Android and iOS versions are in scope for each technique, stated separately?
- How is framework code handled: compiled Dart in Flutter apps, JavaScript or Hermes bytecode in React Native apps?
- Which third-party SDKs and native libraries in your app are covered or left alone?
Evidence
- Open the protected build with a decompiler and a disassembler and record what your engineers can still read.
- Attach a debugger and a hooking tool in an authorised lab and record the signal and response.
- Patch a check, re-sign the app and confirm the modified copy is detected.
User impact
- Measure app size and start-up time on devices you choose, before and after protection.
- Confirm crash reports still symbolicate: mapping files on Android, dSYM files on iOS.
- Run install, update and your most sensitive journey on both platforms.
How Otukan answers. Otukan fits your existing build and release pipeline, and your signing keys stay with your team. Crash reporting keeps working on both platforms. We run the analysis tests above with your engineers and expect you to measure size and start-up yourself.
A deeper look at obfuscation choices is covered on the code obfuscation guide.