Mobile app security evaluation checklist

Before you select mobile app protection, your team should settle three things: a written description of your own app, threats and responsibilities; evidence from each option for your platforms, OS versions and release process, not a feature list; and a decision record that says who owns what afterwards. This checklist is for security leads and mobile engineers running that evaluation. It shows how Otukan answers each area, so you can see what good evidence looks like. Nothing here replaces testing on your own builds and devices, and Otukan welcomes that test.

Why each area matters is covered on the evaluation criteria page. Background on the controls themselves is covered on mobile app shielding.

Requirements worksheet

Complete this section internally before the first call.

App architecture

• Which platforms are in scope: Android, iOS or both, and which minimum OS versions do you support on each?
• How is the app built: native Kotlin or Java, Swift or Objective-C, Flutter, React Native or a mix?
• Which native libraries, third-party SDKs and embedded web content ship in the app?
• What does the release output look like: Android App Bundle or APK, iOS archive, and any separate builds per market?
• How is the app signed and delivered: Play App Signing, App Store distribution, enterprise or private channels?

Threats and assets

• Which assets need protection: business logic, API keys and endpoints, stored data, user sessions, in-app value?
• Which attacks matter most: reverse engineering, repackaging, runtime hooking, automated API abuse, account takeover?
• Which findings from penetration tests or store reviews are still open?
• Which standards does your organisation map mobile controls to, such as OWASP MASVS?

Responsibilities

• Who owns the protected build in your pipeline, and who approves a change to protection settings?
• Who receives runtime signals, and which backend service acts on them?
• Who decides the response for each user flow, from observe to terminate?
• Who supports legitimate users affected by a false positive?

Evidence requests

Ask for answers in writing, separately for Android and iOS. After each area, you will find how Otukan answers it.

Platform and version scope

• For each control, which Android versions and which iOS versions are in scope?
• Which frameworks are in scope, and how is framework code protected, for example compiled Dart code in Flutter apps or Hermes bytecode in React Native apps?
• Which controls are platform-specific, and what covers the same risk on the other platform?
• How are new OS releases handled and communicated?

How Otukan answers. Otukan protects Android, iOS, Flutter and React Native apps, and every control carries its own Android scope and its own iOS scope. Root detection is an Android control; jailbreak detection is an iOS control. You receive a per-control scope for the OS versions you support before a protected build ships.

Integration and release

• How does protection fit your build and release pipeline, and who signs the final build?
• On Android, how does protection work with R8 or ProGuard rules and the mapping files your crash reporting uses?
• On iOS, how does protection work with symbol stripping, dSYM files and crash symbolication?
• How do integrity checks behave with Play App Signing on Android and App Store distribution signing on iOS?
• Can protected builds run in your own CI/CD pipeline without sending source code outside your organisation?

How Otukan answers. Otukan fits your existing build and release pipeline as a repeatable step in every release. Your signing keys stay with your team, and protection is designed to work with Play App Signing and App Store distribution signing. Crash reporting keeps working: mapping files on Android and dSYM symbolication on iOS stay part of your release.

Repeatable testing

• Can you reproduce each detection in your own authorised lab with documented steps?
• What test plan covers false positives: devices, manufacturers, OS versions, expected results and reviewer?
• What is the effect on app size, start-up time and your most sensitive flows, on devices you choose?
• Which bypass techniques does each control address, and how is that documented?

How Otukan answers. Otukan detects hooking frameworks, debuggers, emulators, rooted Android devices, jailbroken iOS devices and modified or repackaged copies while the app runs. We walk your engineers through reproducing each detection in your authorised lab, and we expect you to measure app size, start-up and your key flows on your own devices.

Operations and data

• What data do runtime signals contain, where are they sent and who can access them?
• Can signals go to your own backend so that your server makes the decision?
• How are protection settings changed after release?
• How does each control behave when the device is offline or your signal endpoint cannot be reached?
• What happens to protected builds already in users’ hands if the relationship ends?

How Otukan answers. Otukan sends runtime threat signals to your own backend, so your server decides whether to step up authentication, limit a session or refuse a request. In the app, you set a response per user flow: observe, warn, restrict or terminate. We document the signal content with you during the technical review.

The integration page covers build and release in more detail.

Decision record

Close the evaluation with a short written record. It protects the decision when people, platforms or suppliers change.

What to record

• The requirements worksheet as it stood when the decision was made.
• For each option: the evidence received, the tests you ran and the results, per platform.
• Items each option could not evidence, stated plainly rather than scored.
• The total cost you expect to carry, including integration effort, testing and support.
• The accepted risks, who accepted them and the date.

How to compare options

Per-control scope record

Keep one table per option so that platform gaps stay visible. Fill every cell from the written answer and your own test result.

Avoid single numeric scores: a weighted total hides the one missing Android or iOS control that may matter most.

If your app is already published, the free App Exposure Check reviews the public store release and gives your threats section a head start. For the full product, see mobile app security.