Otukan protects your app’s secrets in each place they live: the package anyone can download, memory while the app runs, and the screen in front of the user. It obfuscates and encrypts what ships, guards sensitive values while they are in use, and controls what leaves through screenshots, the clipboard and the keyboard. Evaluate it by testing each of those places on your own build. It covers Android, iOS, Flutter and React Native apps, with each control scoped per platform. It raises the cost of extraction sharply, and keys that grant real power still belong on your server.
Where code and data are exposed
Every public app is handed to its attackers. Anyone can download it from Google Play or the App Store, unpack it on a desk and read it at leisure. An Android package decompiles to something close to readable code. An iOS binary takes more effort, but once decrypted on a jailbroken device it opens to the same disassemblers. Reverse engineering protection raises the effort that analysis takes. Nothing about the attack needs your servers, so your network defences never see it.
The trust boundary for this topic is therefore the app itself. Three flows cross it.
| Where the secret sits | What an attacker takes | Otukan control |
|---|---|---|
| In the package | Business rules, endpoints, embedded keys, bundled models and configuration | Code obfuscation, binary protection, asset and resource encryption |
| In memory | Session tokens, decrypted values, keys in use | Memory data protection, runtime checks against debuggers and memory readers |
| At the interface | Account numbers, statements, documents on screen | Screen capture controls, clipboard limits, keyboard protections |
For many apps, the first row is the costliest. A discount rule, a fraud threshold or an unreleased feature flag read from your package gives a competitor or a fraud ring a map of your app. The second row matters most for payments, identity and health apps, where a value decrypted for a moment can still be dumped. The third row is where regulated customer data escapes quietly, through a screenshot synced to a cloud gallery or a number pasted into another app.
Who protects what
What the operating system provides
Both platforms give you a strong base. Each app runs in its own sandbox. Android offers the Keystore, which can hold keys in hardware-backed storage on devices that support it. iOS offers the Keychain and Data Protection classes that tie file encryption to the device passcode. Use them. They assume, though, that the device itself has not been compromised, and they do nothing to hide your code or the logic inside it.
What Otukan adds in the app
Otukan works on the parts the platform leaves open. It makes compiled code hard to read, encrypts strings and bundled assets, keeps key material out of readable code and in platform-backed storage, and shortens the life of decrypted values in memory. At the interface, it blocks capture on sensitive Android screens and detects recording and mirroring on iOS, where apps cannot block screenshots outright. For the obfuscation layer in detail, see code obfuscation.
What stays on your backend
Some secrets should never ship. Signing keys for payments, credentials for partner systems and the authority to change prices or limits belong on servers you control. Otukan highlights embedded values that fall into that category, so your team can move them out of the app and replace them with scoped, short-lived tokens.
How to evaluate code and data protection
Platform scope
Ask for scope per control and per platform, not per category. Screen capture behaves differently on Android and iOS; Flutter and React Native package code differently from native apps. Otukan documents each control against each platform, and your evaluation should test the platforms and frameworks you actually ship.
Evidence you can reproduce
The best proof is one you run yourself. Take a protected build of your own app and a baseline build. Decompile both, search them for your API hostnames, feature flags and known strings, and compare what an analyst can still read. On a test device, attach a debugger or memory reader and confirm that sensitive values are cleared and the detection reaches your backend. The protection report for each build tells you what was covered, so you can check nothing sensitive shipped in clear text.
User impact
Protection has to leave the app fast and stable. Measure start-up time, app size and crash rate on your target devices, with the same build compared before and after protection. Keep crash reporting readable with the mapping file from each build. Test screen capture rules with the people who rely on accessibility tools and screen readers, so a control meant for attackers never gets in a customer’s way. Measurement methods are covered on performance and compatibility.
To see how exposed your published app is today, request a free App Exposure Check of the public store release.