Evaluate anti tampering by settling three things in order: what counts as your genuine app, every legitimate way that app can change between your build server and a customer’s phone, and what should happen in the app and on your backend when a copy falls outside that. A solution that checks the wrong boundary misses modified copies. One that ignores authorised change flags your own releases. One without a clear response produces events nobody acts on. This guide covers Android and iOS apps, including Flutter and React Native, with each platform’s signing rules treated separately.
The Otukan control is covered on mobile app anti-tampering.
Integrity boundary
List what a check must protect. Each item below can be changed on its own, so each needs its own answer.
Binary
The executable code: DEX files and native libraries on Android; the Mach-O executable and embedded frameworks on iOS. Removing a licence check or a security check means changing the binary.
Bundle
Everything shipped beside the code: resources, configuration, certificates and models. In React Native apps the JavaScript bundle lives here; in Flutter apps the assets ship here while Dart is compiled into native code. Changing an endpoint or a feature flag often touches only the bundle.
Signature
The certificate on Android, or the team identifier and provisioning on iOS. Any change to binary or bundle breaks the original signature, so a modified copy must be re-signed with someone else’s identity.
Runtime state
Code and data in memory after launch. A hooking tool can change a function without touching the package, so a package check alone does not see it.
- For each boundary, does the solution check it on Android and on iOS, stated separately?
- Where do the checks run, and how are the checks themselves protected from removal?
- When do checks run: launch only, or again before sensitive actions?
How Otukan answers. Otukan checks all four boundaries: executable code, bundled content including React Native bundles and Flutter assets, the signing identity and code in memory. Checks run at launch and repeat before the actions you mark as sensitive, and each event says which boundary differed.
Authorised changes
Before any test, write a register of every legitimate difference between the build you produce and the app your customers run.
| Channel or change | Android question | iOS question | Expected by the solution? |
|---|---|---|---|
| Store signing | Is Play App Signing enabled, and which certificate do users receive? | Which distribution identity does the App Store apply? | |
| Store delivery | Which split APKs and on-demand modules does Google Play deliver from your App Bundle? | Which thinned variants and on-demand resources does the App Store deliver? | |
| Beta and testing | Which testing tracks and keys are used? | Which TestFlight, ad hoc or development identities? | |
| Managed or private distribution | Which managed or private channels? | Which custom app or enterprise channels? | |
| Content updates after release | Do you ship content or script updates outside the store? | Do you ship content or script updates outside the store? | |
| Key rotation | When will a signing key next change? | When will a certificate next change? |
- Complete every row for every app, and name the owner of each channel.
- Ask each solution how it learns this register and how it is updated before a rotation or new channel.
- Confirm that an update from your previous release to the new one passes on both platforms.
How Otukan answers. Otukan is configured with the signing identities and channels you list for each build, and the register is updated before a key rotation or new channel reaches customers. Legitimate builds pass by design; we confirm it by installing each channel’s build in testing.
Response
An integrity event should reach two places: the app, for an immediate reaction, and your backend, for the decision that a modified copy cannot rewrite.
| Integrity event | App behaviour to consider | Backend behaviour to consider |
|---|---|---|
| Binary changed | Restrict sensitive screens | Refuse sessions from the flagged install |
| Bundle changed | Stop loading the changed content | Step up before account changes |
| Unknown signing identity | Warn and offer the official store link | Treat all requests from the install as untrusted |
| Code changed in memory | End the sensitive flow | Refuse the request that carried the event |
Validate the mapping
- In an authorised lab, build a modified copy for each boundary and confirm the expected event and response.
- Install a build from each legitimate channel and confirm nothing fires.
- Update from the previous release, sign in and complete your most sensitive journey on the protected build.
- Record platform, OS version, device, result and reviewer for each run.
How Otukan answers. Otukan sends each integrity event to your backend with the request it concerns and applies the response you set per flow: observe, warn, restrict or terminate. We run the modified-copy and legitimate-channel tests with your team before release.
Repackaged copies are covered on repackaging and re-signing detection, and the wider integrity programme is covered on application integrity.