Evaluate an integration by where it touches your system and who owns each touchpoint. Otukan touches three places: your release pipeline, where protection is applied to every release build; the app on your users’ devices, where its controls detect threats and respond; and your backend, which receives Otukan’s signals with sensitive requests and decides what a risky session may do. For each touchpoint, ask what changes, who owns it and how you verify it. Otukan covers Android and iOS apps, including Flutter and React Native, planned separately per platform. It fits the pipeline you already run, and your signing keys stay with you.
The flows and boundaries an integration touches
An integration is easier to judge when it is described by the flows it protects, not by the tools it uses. Start with the journeys where a compromised device or a modified app costs you most.
| Touchpoint | Mobile flow affected | Trust boundary | What changes |
|---|---|---|---|
| Release pipeline | Every release build, per platform | Between your source code and the artefact users install | One protection step with a versioned profile, before your signing |
| App on the device | Launch, sign-in, payments, account recovery | Between your app and a device or tools you do not control | Controls that detect hooking, tampering, debugging, rooted or jailbroken devices and emulators, and respond per flow |
| Backend | Sensitive API requests from the app | Between the app and the services that hold value | A signal arrives with each sensitive request; your server decides |
| Security operations | Monitoring and investigation | Between what apps report and what your team acts on | Reports per app version and platform |
Begin with the flows that carry value
Pick two or three flows for the first release, for example sign-in and payment confirmation. Protecting those well, with responses your backend understands, teaches both teams more than switching on every control at once. Later flows reuse the same profile, backend handling and release process.
Who does what: app, operating system and backend
Otukan does not replace what the operating system or your server already does. Each layer keeps its own job.
| Responsibility | Otukan in your app | Operating system and platform services | Your backend |
|---|---|---|---|
| Code protection | Obfuscates and protects your code and framework layer | Enforces code signing and sandboxing | Not involved |
| Runtime integrity | Detects hooking, tampering, debuggers, emulators, rooted or jailbroken devices | Offer platform attestation: the Play Integrity API (Google Play services) on Android, App Attest on iOS | Verifies the attestation result and reads Otukan’s signal |
| Response | Applies the response you set per flow: observe, warn, restrict or terminate | Not involved | Allows, steps up or refuses the request |
| Evidence | Reports signals per app version | Not involved | Logs decisions with the session |
The platform is a strong base, but it does not know your business flows. Your backend knows the flows but cannot see the device. Otukan sits between the two: it sees the device from inside your app and hands your server a signal it can act on.
What your team provides
- a description of your apps, targets, extensions and frameworks, per platform
- how your pipeline builds, signs and releases today
- the flows in scope and who approves responses for each
- the services that authorise sensitive requests
Otukan’s engineers plan from that description. Binaries, signing material and production data stay on your side.
Evaluating the fit
Judge an integration on evidence you can repeat, per platform. Otukan works through each of these checks with you, on your own app and pipeline.
| Check | What to ask for | Evidence form |
|---|---|---|
| Platform scope | Which controls apply on Android and which on iOS, and on which versions | A per-control matrix for each platform |
| Framework fit | How the Flutter or React Native layer is protected, not only the native shell | A protected build of your app, tested on devices |
| Pipeline fit | Where protection sits relative to signing, tests and release | A run on a branch of your real pipeline |
| Backend fit | What the signal contains and how your server reads it | A test request flagged on a prepared device |
| User impact | How legitimate users on older or managed devices are treated | Results from your own device list |
| Operations | Who sees reports and how a wrong response is corrected | An agreed runbook |
Android and iOS results stay separate throughout. A control that works on one platform says nothing about the other until it is shown there.
For signing and key ownership, see mobile app signing security. Pre-release test planning is covered on protected mobile app testing. Device, OS and speed criteria are covered on compatibility and performance. For the pipeline view, return to mobile DevSecOps. Proving a switch to Otukan on a staged release is covered on migration and adoption.