Compare mobile app protection options on four criteria: which threats each control handles on each of your platforms, how protection enters your build and release process, what it costs your app while it runs, and who keeps it working as operating systems change. Judge every criterion on evidence you can repeat on your own builds, not on feature lists or category names. This page explains why each criterion matters and what proof settles it. Otukan answers all four for Android, iOS, Flutter and React Native apps, and invites you to test every answer on your own build.
The question-by-question worksheet is covered on the evaluation checklist.
Decision criteria
Evaluations that compare one feature list with another tend to find the gaps after release. The four criteria below keep attention on what your app will actually receive, and on the evidence that proves it.
Supported threats
A category such as “runtime protection” hides the detail that matters. One option may handle hooking frameworks but not emulators; another may cover rooted Android devices but treat jailbroken iOS devices differently. Ask for each threat by name, and for each platform on its own.
Otukan names the threat behind every control and gives it a separate Android scope and iOS scope. Root detection is an Android control and jailbreak detection is an iOS control, each built for its platform.
Integration
Protection that sits outside your release process gets skipped under deadline pressure. The strongest evidence is a protected build of your own app that went through your own pipeline and was signed by your own team.
Otukan fits your existing build and release pipeline, and your signing keys stay with you.
Performance
Users notice slow start-up and hesitant payment screens long before they notice security. A generic figure measured on someone else’s app on a flagship phone says little about yours.
Otukan runs its runtime checks at launch, at sign-in and before the sensitive actions you mark, and measures the effect with your team on devices you select, including the oldest you support.
Lifecycle
Android and iOS change every year, frameworks change more often, and attack tooling changes constantly. A control that works today needs an owner who keeps it working.
Otukan maintains its controls as the platforms and supported frameworks change, and names who responds when a check misbehaves on a legitimate device.
Scorecard with evidence fields
Use one scorecard per option. Fill the evidence column from what you received and tested; leave it empty rather than estimating.
| Criterion | What to ask for | Evidence field | Weak evidence looks like |
|---|---|---|---|
| Threat coverage | A written scope per control, per platform | Scope statement plus your lab result | A single tick against a category |
| Integration | A protected build of your own app | Pipeline run record and signing record | A demonstration on a sample app |
| Performance | Measurements on devices you choose | Method, devices, OS versions, date, result | A figure with no method attached |
| Lifecycle | How protection keeps pace with OS and framework releases | Named owner and a documented process | A general promise to stay current |
| Signals and response | A sample signal and the response options per flow | Signal content reviewed by your backend team | A dashboard screenshot only |
Evidence collection
Evidence is only useful if it survives a second look. Plan the collection before the first call, so every option is tested the same way.
Repeatable tests
A test is repeatable when someone else on your team can run it next month and reach the same result. That means recording the build, the device model, the OS version, the authorised tool used, the expected signal, the observed signal and the reviewer.
- Did we run each detection against a protected build of our own app rather than a sample app?
- Did we walk the same user flows on ordinary devices to see what legitimate users experience?
- Did we record build, device, OS version and reviewer for every run?
- Could a second engineer repeat each run from the notes alone?
Platform-specific scope
A pass on Android tells you nothing about iOS, and a pass in a native app tells you little about a Flutter or React Native app. Ask for scope per platform and per framework layer, and test each one separately. Otukan supplies that scope per control, so the gaps and the strengths are both visible.
A pilot that answers one question
Decide before the pilot starts what it must prove: which flows, which devices, which signals must reach which backend service, and what counts as a false positive. Otukan can run your pilot in observe mode, so signals reach your backend without changing what users see, and you judge the results on your own traffic. Otukan also shares a sample of its signal content for your backend team to review.
Commercial fit
Otukan does not publish a rate card, because the right scope depends on your apps and not on a standard package. Commercial terms are agreed directly with you once the technical picture is clear.
What shapes scope
- The platforms and frameworks in each app, and how many apps are involved.
- The controls you need, from code obfuscation to runtime self-protection and API evidence.
- Where runtime signals go and who acts on them.
- How often you release, and the support you expect between releases.
What to bring to the first conversation
- Which apps and platforms are in scope, and which framework each one uses?
- Which threat, audit finding or incident started the evaluation?
- Who will own the protected build, the response policy and the signals?
- What would a successful pilot show your security lead and your mobile lead?
We never ask for binaries, signing keys or production credentials at this stage. If your app is already in a store, the free App Exposure Check reviews the public release and gives your evaluation a documented starting point. For the product overview, see mobile app security. Planning a move to Otukan app protection is covered on migration and adoption.