Evaluate asset and resource encryption by starting with the files, not the cipher. List what your app ships besides code, mark the files that would hurt you if copied or changed, and test three things: those files are unreadable in the downloaded package, their keys add no service for your team to run, and a swapped file is refused. Otukan delivers all three for Android, iOS, Flutter and React Native apps. It encrypts marked assets in the protected build, decrypts them only as your app loads them and refuses changed files. Once content is decrypted for use, Otukan’s runtime checks guard it.
Data inventory
An Android package and an iOS app bundle are both archives. Anyone who downloads your app can open them and browse every file inside. On iOS, the App Store’s distribution encryption applies to the executable, not to the resources that sit beside it, so bundled files are readable once the archive is unpacked. On Android, the assets and raw resource folders open just as easily.
Start the evaluation with a table like this one, filled in for your own app.
| Asset | Typical location | What an attacker gains | Encrypt? |
|---|---|---|---|
| Environment and endpoint configuration | Bundled JSON or property files | Hidden APIs, staging servers, feature switches | Yes |
| Script bundles | The JavaScript bundle of a React Native app; local web content in hybrid screens | Business logic in near-readable form | Yes |
| On-device models and rule tables | Model files, scoring tables, fraud rules | Your trained know-how, ready to reuse | Yes |
| Licensed or paid media | Images, audio, video, game levels | Content you pay for or sell | Usually |
| Flutter assets | The app’s bundled asset folder | Whatever your team placed there | Case by case |
| Icons, fonts, generic images | Standard resource folders | Nothing of value | No |
Two questions decide each row. Would a copy of this file help someone build a rival product, bypass a rule or resell your content? Would a changed copy let someone alter how the app behaves? A yes to either marks the file for encryption.
Where the storage boundary sits
Asset encryption protects files inside the package. It is a different boundary from data your app writes to the device after install, which belongs to Android app data encryption and iOS app data encryption. Keeping the two separate stops a team from assuming that one control covers both.
Key lifecycle
Asset keys have an unusual profile. Every user receives the same files, so there is no per-user key to create or recover. What matters is who generates the key, where the app finds it, and what happens when a release changes.
| Stage | Responsibility | What to ask during evaluation |
|---|---|---|
| Generation | Otukan, during the protected build | Are keys generated for each protected release? |
| Access | The protected app, at load time | Is the key material hidden from the code a decompiler shows? |
| Rotation | Each new protected release | Does a new release stop old extracted material from being reused? |
| Recovery | Rebuild from source | Is there anything your team must back up? |
With Otukan, the asset keys belong to the protected build. Your team does not run a key service for these files and has nothing extra to back up: rebuilding from source produces a fresh protected release. Signing keys never leave your team.
Keys that do not belong here
Asset keys protect files that are the same for everyone. Keys that protect a user’s own data, sign requests or unlock an account belong in platform-backed storage or on your server. For that side of key handling, see cryptographic controls.
Runtime scope
An app cannot use a file it cannot read. At the moment of load, the protected app decrypts the asset into memory and hands it to the code that needs it. That moment defines what asset encryption does and does not do.
What it stops
- Reading configuration, scripts, models and media from a downloaded package.
- Dropping a changed file into the package and having the app trust it.
- Copying licensed content out of the app and reusing it elsewhere.
What it does not stop on its own
- An analyst with a debugger attached at the moment of load.
- Instrumentation that reads the decrypted content from memory.
- Screen recording of media the app is playing.
Otukan answers these with runtime controls that sit alongside asset encryption: debugger and instrumentation detection during load, memory safeguards for decrypted content and capture controls on sensitive screens. Each one sends its signal to your backend, so a bypass on the device is visible on your side. Runtime safeguards for decrypted values are covered on memory data protection.
Proving it on your app
Before a protected release ships, your team and ours run three tests on the files you marked. In an authorised lab, we unpack the protected package and confirm the marked files are unreadable, then swap one and confirm the app refuses it and the tamper signal arrives. On a legitimate device, the same journey completes with no signal. Install, update, sign-in and the flows that load protected content are then repeated, with OS versions, devices, results and reviewer recorded.
Asset encryption is one of several package and runtime controls; return to code and data protection for the full set.