Evaluate code protection against your own app, not a sample the supplier chose. Begin with an inventory of the logic, strings and dependencies that would harm you if someone read them. Then protect a real release build and give the protected and unprotected versions the same analysis tasks, so the difference is measured rather than described. Finally, judge the result on what it costs your engineers in debugging, crash diagnosis and release upkeep. Obfuscation makes analysis slower and costlier; runtime checks cover what happens once the app is running. Android, iOS, Flutter and React Native each get their own test.
What Otukan’s obfuscation does is covered on mobile code obfuscation. Other buyer aids are on solution guides.
Build a code inventory
An attacker reads the parts of your app that pay off. Your inventory should name those parts before any tool touches the build.
Sensitive logic
- Which code decides money, access or entitlement: fee and discount rules, licence checks, reward logic, transaction signing?
- Which code talks to your backend, and which request formats would help someone script your API?
- Which code contains your own security checks, which an attacker would look for first?
Strings and embedded data
- Which endpoints, lookup keys, feature flags and error messages sit in the binary as readable text?
- Which configuration files and bundled assets reveal how the app works?
- Are any secrets embedded that should instead come from the server at run time?
Dependencies and framework layers
Where your code lives decides which protection applies. Record it per platform.
| Asset | Where it sits on Android | Where it sits on iOS |
|---|---|---|
| App logic | DEX bytecode from Kotlin or Java | Compiled Swift or Objective-C code, with Objective-C class and selector names readable in runtime metadata |
| Native code | Shared libraries in the APK or bundle | Frameworks and dynamic libraries in the app bundle |
| Flutter code | Compiled Dart in the app’s native library | Compiled Dart in the app framework |
| React Native code | JavaScript or Hermes bytecode bundle in assets | JavaScript or Hermes bytecode bundle in the app bundle |
| Third-party SDKs | Vendor libraries and their rules | Vendor frameworks |
Design the test: baseline against protected
A fair test holds everything constant except protection. Build both versions from the same commit, with the same configuration, as release builds.
Analysis tasks
Run these tasks on both builds in an authorised setting, and note what the analyst recovered and how hard it was:
- Find the function that performs a named sensitive action, starting from its screen.
- Search the binary for a known endpoint or error message.
- Follow the path from a button tap to the network call it triggers.
- Locate a native function by name and read its logic.
- Recover readable Dart or JavaScript logic from a Flutter or React Native build.
- Remove one of the app’s own security checks and run the result.
Recording results
| Task | Baseline build | Protected build | Analyst notes |
|---|---|---|---|
| Find a sensitive function | Recovered or not | Recovered or not | Effort and route taken |
| Find a known string | Recovered or not | Recovered or not | Where it appeared |
| Trace a flow to the network | Recovered or not | Recovered or not | Where the trail broke |
| Remove a security check | Ran or not | Ran or not | What stopped it |
How Otukan answers. Otukan renames classes, methods and fields to meaningless names, stores strings in protected form until the moment they are needed, restructures control flow in the code you choose, protects bundled configuration and assets, and strips and transforms C and C++ native libraries. It protects Dart code in Flutter apps and JavaScript or Hermes bytecode in React Native apps directly, not only the native shell around them. Our engineers sit with yours to compare decompiled output of both builds, task by task. Task six is where obfuscation meets anti-tampering: Otukan hides its own integrity checks inside the protected code, detects altered code at run time and sends a tamper signal to your backend.
Decide on debugging, crash diagnosis and upkeep
Protection your engineers cannot live with gets switched off. Weigh these criteria as heavily as the analysis results.
Debugging
- Can developers keep debugging unprotected builds while QA tests protected ones?
- How are names kept for reflection, serialisation, dependency injection and third-party SDKs?
Crash diagnosis
- Does each protected build produce a private mapping file your crash reporting can use?
- Do dSYM files on iOS and native symbols on Android still translate stack traces?
- Has a deliberate test crash in the protected build been translated back to readable source lines?
Release maintenance
- Is protection configuration kept in version control and reviewed like code?
- What happens when a new dependency arrives or a keep rule is missing?
- Can heavier transforms be limited to sensitive code?
| Criterion | Question to answer | What good looks like |
|---|---|---|
| Debuggability | Can engineers work normally? | Protection applies to release builds only |
| Crash diagnosis | Are traces readable? | Test crash maps back to source |
| Upkeep | Does each release need manual work? | Configuration is versioned and repeatable |
| Scope control | Can protection be targeted? | Heavier transforms where you choose |
How Otukan answers. Every protected build ships with a private mapping file, and native symbols stay available to you for crash analysis. Otukan maintains the keep list with your team and leaves third-party SDKs as their vendors ship them. Each release also comes with a list of the strings Otukan protected, so reviewers can confirm the sensitive ones were covered. It fits your existing build and release pipeline, and your signing keys stay with your team. To turn industry mobile security index findings into a test of your own binary, see mobile security index analysis.
The wider comparison with build-tool shrinking is covered on ProGuard vs mobile app shielding. The wider evaluation against reverse engineering is covered on the anti reverse engineering solution guide.