A mobile security team should evaluate compatibility and performance as release criteria that are checked again whenever something changes, not as a single benchmark at purchase. Write down what a protected build must meet on start-up, stability, size and your key flows. Test it on the physical devices and OS versions your users have, including legitimate set-ups that can look unusual. Then repeat those checks for every OS release, framework upgrade and protection change. Otukan supports that loop for Android and iOS apps, including Flutter and React Native, with each platform judged on its own. For the measurement method in detail, see mobile app protection performance.
Where compatibility and performance meet risk
The flows users notice most are often the flows protection guards most closely. That is where the evaluation should concentrate.
| Flow | What users notice | What a protection check can affect | What to watch |
|---|---|---|---|
| Cold start to first screen | Time before the app is usable | Checks placed at launch | Start-up time per device |
| Sign-in | Delay or unexpected prompts | Device and integrity checks before credentials are sent | Flow latency and completion rate |
| Payment or transfer | Friction at the moment of value | Checks before a sensitive request | Latency and abandonment |
| Background work | Battery drain or missed syncs | Checks that run while the app is not in front | Battery and background limits |
| Update and install | Failed updates, crashes after update | Changes in the protected artefact | Install success and crash rate per version |
The boundary is the legitimate user’s device
Otukan is built to react to devices and tools you do not control. The compatibility question is the mirror image: a legitimate user on an unusual but honest set-up. Older phones, manufacturer-customised Android builds, accessibility services, work profiles and managed iPhones all belong in the test, because those users are customers, not attackers.
Who is responsible for what
Compatibility is shared work between the app, the operating system and your backend. Knowing which layer owns a problem shortens every investigation.
| Layer | Its part in compatibility and performance |
|---|---|
| Otukan in your app | Places each check at the moment you choose per flow, and reports what it sees per app version |
| Operating system | Changes APIs, background limits, permissions and platform services with each release, differently on Android and iOS |
| Your backend | Handles a missing or late signal sensibly, and decides responses without blocking on a single check |
| Your team and Otukan’s engineers | Own the criteria, the device list and the re-checks, per platform |
Changes that trigger a re-check
- a new major Android or iOS release, or its developer preview ahead of public release
- a new Flutter or React Native version, or a toolchain upgrade
- a new third-party SDK in the app, especially one that inspects or hooks the app
- a new device family that appears in your user base
- a change to the protection profile, such as a new control or a moved check
Each change runs the same agreed checks. The result is a short record your release owner can read before approving. Testing symbols, start-up and dependencies across each layer of a release is covered on the SDK protection solution guide.
Evaluation criteria
Supported platforms
Ask for the supported versions of each control, per platform, and compare them with your own analytics. A control that applies on Android says nothing about iOS until it is shown there. For how environments are scoped, see supported environments.
Evidence
| Criterion | Question to ask | Acceptable evidence |
|---|---|---|
| Version scope | Which OS versions does each control support? | A per-control matrix for each platform |
| Device spread | Does the build install, update and run on your device list? | Results per device from your protected build |
| Framework layer | Is the Dart or JavaScript layer tested as well as the native shell? | Framework-specific test runs |
| Third-party SDKs | Do analytics, payment or fraud SDKs still work? | Functional results with each SDK in place |
| Change handling | What happens on the next OS release? | A re-check record from a previous change |
User-impact checks
Measure what legitimate users experience, not only whether attacks are caught. Count legitimate sessions that received a warning or restriction during testing and the staged rollout. Review each one: either the signal was right, or the response for that flow should move to observe. Otukan lets you choose the response per signal and flow, so a correction is a profile change, not a rebuild of your logic.
Set the gate in your pipeline
Put the criteria in the release pipeline. A protected build that misses one stops there until the cause is found. To see how these gates sit among the other release stages, return to mobile DevSecOps.