Almost all of your app can be obfuscated, and Otukan does it while keeping your app’s behaviour intact. It renames your own classes and methods, protects the strings your app carries, reshapes the order of your most sensitive logic, and hardens bundled resources, native libraries and Flutter or React Native framework code. Names stay unchanged only where the app or its libraries look them up while running, such as classes used through reflection, fields read by serialisation and entry points that SDKs call. Those go on a keep list. The result is code that takes much more time and skill to understand, with crash reports your team can still read.
For combined static and runtime protection, see mobile app shielding.
Protected material
An app holds several kinds of material, and each needs its own technique. Otukan treats them separately and applies the heaviest protection where an attacker gains the most.
| Material | What an analyst reads without protection | Android notes | iOS notes | What Otukan applies |
|---|---|---|---|---|
| Code identifiers | Class, method and field names that explain the code | DEX bytecode decompiles to near-source Java or Kotlin; R8 renames identifiers when minification is enabled | Objective-C class and method names stay in the binary for the runtime; Swift keeps type metadata | Identifier renaming beyond the platform baseline |
| Strings | Endpoints, error messages, feature flags, lookup keys | Visible in the DEX string pool and resources | Visible in the Mach-O string sections | String protection, decoded only when needed |
| Control flow | The sequence of checks and decisions in sensitive logic | Readable in decompiled bytecode | Readable in disassembly and decompiler output | Control-flow obfuscation on the code you choose |
| Resources and assets | Configuration files, bundled scripts, certificates, models | Stored in the package’s resources and assets | Stored in the app bundle alongside the executable | Resource and asset protection |
| Native libraries | Algorithms written in C or C++ | Shared libraries per ABI; not touched by R8 | Compiled into the executable or embedded frameworks | Symbol stripping and native transforms |
Proprietary scoring logic and anti-fraud checks justify heavier protection than screens and layouts, and Otukan lets you set that balance. Private keys and other secrets belong on your server rather than in the app; obfuscation protects the code and data that have to ship.
For iOS detail, see iOS code obfuscation.
Compatibility
Obfuscation breaks apps in predictable places, and Otukan handles each one by design.
Reflection and dynamic lookup
Code that finds a class or method by name at run time fails if that name changes. On Android this includes reflection, dependency injection frameworks and classes named in the manifest. On iOS it includes selectors, key-value coding and classes named in storyboards. Otukan keeps those names and protects the code around them.
Serialisation
Libraries that map JSON or stored data to fields by name read the wrong keys if field names change. Otukan keeps the names of those model classes, or works with the explicit key annotations your code already uses.
Third-party SDKs
SDKs arrive already built, and many publish their own keep rules. Otukan leaves vendor code as shipped, respecting the vendor’s terms, and protects your own code that calls it. If you ship an SDK of your own, mobile SDK protection covers protecting it inside other companies’ apps.
Cross-platform code
Flutter compiles Dart ahead of time into a native library and offers its own symbol obfuscation option. React Native ships a JavaScript or Hermes bytecode bundle that platform tools do not transform. In both cases most of your logic lives in framework code, so Otukan protects that code directly rather than only the native shell. Framework notes are on Flutter app security and React Native app security.
Release support
An obfuscated app still has to be supported in production. Stack traces from users’ devices show the new names, so Otukan pairs each protected build with its mapping.
- Each release build produces a private mapping alongside the platform’s own files (R8 mapping files on Android, dSYM files on iOS).
- Your team stores it with the build, under the same access control as your release artefacts.
- Your crash reporting service receives it, so stack traces are translated automatically.
- A test crash confirms the translated trace points to the right line before the build ships.
Build the protected release the same way every time: a mapping belongs to one build, and reproducible builds keep crash analysis reliable across releases.
Proving it on your app
Otukan verifies obfuscation with your team on your own build. Together we decompile the protected build with common public tools and compare it with the unprotected one, then run install, update, sign-in and your sensitive flows on real devices, recording size and launch time for both. For performance testing, see mobile app protection performance. A longer method is in the mobile code obfuscation guide.
For the wider protection model, return to mobile app security. If your app is already published, start with a free App Exposure Check of the public store release.