Most mobile apps need static and runtime protection working together, and Otukan shielding delivers both in one profile. Static protection makes the shipped package hard to read and change: obfuscated code, protected strings and built-in integrity data. Runtime checks notice when the running app is debugged, hooked, modified or placed on a compromised device, and apply the response you choose. The right mix depends on what an attacker gains from your app, so Otukan starts from your threat model rather than a feature list. Android and iOS each get controls built for that platform, proved on your own signed build.
For runtime mechanics, see mobile RASP.
Shielding layers
Each layer answers a different attacker question. Obfuscation decides how long it takes to understand your code. Tamper resistance decides whether a changed copy goes unnoticed. Runtime checks decide whether someone can watch or change the app while it runs.
| Layer | What it stops attackers doing | When it acts | How Otukan strengthens it |
|---|---|---|---|
| Obfuscation | Reading logic, algorithms and endpoints from decompiled code | Built into the package, with no runtime switch to turn off | Hides the integrity and runtime checks, so they are hard to find and remove |
| Tamper resistance | Shipping modified code or resources, or re-signing your app | Integrity data built in, checked while the app runs | Repeats checks before sensitive steps, not only at launch |
| Runtime checks | Debugging, hooking, emulation, rooted or jailbroken devices | While the app runs, at launch and before sensitive steps | Sends signals to your backend, so the decision is made where the attacker cannot patch it |
The layers are designed to reinforce each other. Obfuscation makes runtime checks hard to locate. Integrity checks notice when someone strips those checks out and re-signs the app. Runtime checks catch attacks on the live process that no static protection can see. Together they turn quick analysis into slow, costly work.
Choosing a mix
A content app with no account data may need little beyond platform defaults and obfuscation. A banking or payments app usually needs all three layers, with runtime signals sent to the backend. A government or identity app often adds data protection on the device. Otukan builds one profile per app and adjusts it as your risk changes. For a comparison of the two approaches, see app shielding vs RASP.
Deployment fit
Shielding only works if it ships with every release. Otukan fits the pipeline you already run, and we agree each touchpoint with your team before the first protected build.
| Touchpoint | Android | iOS | How Otukan handles it |
|---|---|---|---|
| Build input | Android App Bundle or APK, DEX after R8, native libraries per ABI | Xcode archive or IPA, Mach-O executable, embedded frameworks and extensions | Protects the artefacts you ship, including Flutter and React Native framework code |
| Signing | With Play App Signing, Google holds the app signing key | Apple re-signs App Store builds for distribution | Integrity checks expect the certificate or team identifier your users actually receive |
| Crash reporting | R8 mapping files for deobfuscation | dSYM files for symbolication | Each protected release comes with its own private mapping, so stack traces stay readable |
| Delivery | Google Play, managed enterprise channels, device makers’ stores | App Store, TestFlight, custom and enterprise distribution | Each channel’s build is protected and tested |
| Variants | Flavours and build types | Schemes and configurations | Debug and internal builds are kept free of checks that would block your testers |
Your signing keys stay in your hands. Otukan does not ask for them, because a shielding step that needs your private key widens the set of people and systems able to publish your app. For platform detail, see Android app security and iOS app security.
Validation
Otukan proves every layer on the build your users will receive. We run the plan with your team in an authorised lab, and record what each test shows.
- Static analysis. Decompile or disassemble the protected build with common public tools and compare how much logic, naming and string content remains readable against the unprotected build.
- Integrity. Modify a resource, re-sign the package with a different certificate, install it and confirm the expected tamper signal.
- Dynamic analysis. Attach a debugger and an instrumentation framework, on a rooted or jailbroken test device where relevant, and confirm each runtime check fires with the response you chose.
- Negative control. Run the same user journeys on a legitimate, supported device and confirm nothing fires for real users.
- Regression. Run install, update, sign-in and your most sensitive flow on the protected build, and compare launch time and size with the unprotected build.
Every result is recorded with OS versions, devices, expected and actual outcomes and the reviewer. Attackers adapt their tools, so Otukan treats validation as a repeatable part of each release rather than a one-off sign-off.
The mobile app security evaluation checklist lists the questions to cover. 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.