A mobile security team should evaluate migration and adoption by asking one question at every step: which user flows are protected, by what, in each app version your users actually run. Moving to Otukan means mapping every existing control to an app, operating-system or backend duty, shipping the new protection without a release that carries neither, and proving on a staged rollout that real users are unaffected. This guide covers Android and iOS apps, including Flutter and React Native, replacing a commercial product or in-house checks. It does not cover moving device management; that is a separate evaluation.
For the wider criteria behind any selection, see mobile app security evaluation.
The flows at stake
Migration risk sits in the flows your protection guards today, not in the product you are leaving. Start by naming them.
Map the protected journeys
- Which flows depend on protection today: sign-in, payments, account changes, stored credentials, in-app value?
- For each flow, which check runs, at which moment, and what happens when it fires?
- Which responses are enforced and which only record a signal?
- Which of those behaviours were configured deliberately, and which are defaults nobody has reviewed?
Find the trust boundary
- Where does the decision happen for each flow: on the device, on your server, or both?
- Which backend rules read signals from the current protection, and what do they do when a signal is missing?
- Which older app versions are still in use, and how long will they keep sending the old signals?
The last question matters most. Users update at their own pace, so for a period your backend receives requests from builds protected the old way, builds protected by Otukan and, if the cut-over is planned badly, builds protected by neither. Otukan plans the cut-over release with you so that the third group does not exist.
Where the gaps open
| Moment | What can go wrong | What to plan |
|---|---|---|
| Removing the old protection | A release ships with neither product active | Swap both in the same release, never in consecutive ones |
| Backend rule change | Server rules reject valid requests from new builds, or accept unprotected ones | Rules that recognise both signal sources during the transition |
| First protected release | Checks fire on legitimate users nobody tested for | Observe mode on the first staged release |
| Older versions | Users on unsupported versions keep weaker protection | A minimum-version decision recorded with its date |
Who does what
A clean migration assigns each duty once. Otukan maps your current setup with you and places every control on one of three sides: the app, the operating system or your backend.
App side
Obfuscation, integrity checks, runtime detection and the response a flow applies all live inside the app. These are the controls Otukan replaces directly, with its own protection built separately for Android and iOS. Record, per control, what the old product did and what the Otukan equivalent will do, per platform.
Operating-system side
Some duties belong to the platform, not to any protection product. On Android that includes Keystore-backed keys and Play Integrity verdicts; on iOS, the Keychain and App Attest. Check whether your old product wrapped any of these, because a wrapped platform service that disappears must be called directly or its result passed on another way.
Backend side
Your server holds the final decision for every sensitive request. Otukan sends runtime threat signals to your own backend, so the move changes what the server reads, not where it decides.
- Which services read protection signals today, and who owns each one?
- Can those services accept Otukan signals alongside the old ones for the transition?
- Which server rules will change when the last old version is retired, and who approves the change?
Build and release
Otukan fits your existing build and release pipeline, and your signing keys stay with your team. Remove the old product’s build step in the same change that adds Otukan, so no pipeline run produces a release protected twice or not at all. Signing and release controls are covered on mobile app signing security.
Proving the switch
Adoption is proven on your own releases, with evidence you can hand to the next reviewer.
Platform scope
- For every control in the migration map, is the Android scope and the iOS scope written down separately?
- Are Flutter or React Native builds covered, including framework code, where you use them?
- Which old-product behaviour has no Otukan equivalent on one platform, and what covers that risk instead?
Evidence before rollout
- Has each detection been reproduced in your authorised lab on the protected build?
- Has the same journey run on a legitimate device without any signal firing?
- Do install, update from the previous protected version, sign-in and your most sensitive flow all pass?
User-impact checks during rollout
Otukan runs new controls in observe mode on the first staged release. Nothing changes for users; your team sees how often each check would have acted.
- Compare crash reports, sign-in success and support contacts between the old and new builds.
- Look for signals that fire on groups of legitimate users, such as particular device makers or accessibility tools.
- Tighten responses one flow at a time, starting with the flows where the old product already enforced.
Record the decision
Close the migration with a dated record: the migration map, the tests and results per platform, the minimum app version you support and who owns build, policy and signals from now on. That record is what lets the next team trust the protection they inherit.
If your app is already live, the free App Exposure Check reviews the public store release and shows where your current protection leaves the app readable.