Integrating Otukan asks three things of your team: the build pipeline you already run, approval of a protection profile, and the signing and release steps you already run. Otukan adds protection as one step in that existing build and release pipeline, for Android and iOS apps built natively or with Flutter or React Native. Signing keys, store accounts and the decision to ship stay with you. Otukan’s engineers agree the protection profile with you per app and per platform, then work with your team through releases, toolchain upgrades and policy changes. This page shows who does what, how a protected release flows and how change is handled.
Responsibility map
Who does what
Otukan takes on the protection work. Your team keeps the decisions it already owns.
| Area | Otukan | Your team |
|---|---|---|
| Protection profile | Proposes the controls and the response for each user flow, per platform | Security and product owners approve it and any later change |
| Protection step | Provides the step that applies the profile inside your pipeline, with logs | Runs it as part of the release build |
| Build setup | Tells you what the protection step needs from your build, per platform | Keeps its normal build and adds the step |
| Signing | Never needs your keys | Signs with your release identity, as today |
| Testing | Advises on which flows and devices exercise the runtime checks | Runs protected-build tests on your devices |
| Release | Supplies the profile version and logs for each build | Decides, submits and rolls out |
One integration per platform
Otukan plans the Android and iOS integrations separately, because their build output, signing and store processing differ. For Flutter and React Native apps, Otukan’s engineers plan protection for the Dart or JavaScript layer together with the native shell around it. Where you want your app to react to a runtime signal itself, for example by stepping up authentication before a payment, Otukan’s engineers agree with you which flows get which response, so security and user experience are decided together.
Delivery flow
A protected release follows the same path every time.
| Step | What goes in | Owner | What comes out |
|---|---|---|---|
| Build and protect | Your release variant (an Android App Bundle or APK, or an Xcode archive for iOS) and the approved protection profile | Your mobile team, with the Otukan step in your pipeline | A protected release build, the profile version and logs |
| Sign | Your upload key for Google Play, or your Apple distribution certificate and provisioning profile | Your release owner | A signed, protected build |
| Test | The signed, protected build on physical devices | Your QA team | Results for install, sign-in and sensitive flows |
| Release | Store submission and staged or phased rollout | Your release owner | A protected app in users’ hands |
The protection policy has its own owner on your side. Terminating the app on a signal protects one kind of user and inconveniences another, so the response per flow is a product decision as much as a security one. Otukan makes that choice explicit and versioned.
On Android with Play App Signing, Google re-signs your app, so the certificate on users’ devices is Google’s app signing certificate. Otukan’s integrity checks are set up for the certificate users actually receive.
For pipeline detail, see mobile DevSecOps. The mobile app security evaluation checklist lists the questions buyers ask when they compare options.
Change handling
Updates
Three kinds of change touch a protected app, and each one runs through the same protection step and tests:
- Your releases. Every release build is protected and tested the same way, with no manual stage in between.
- Toolchain and platform changes. New Xcode, Android Gradle Plugin, Flutter or React Native versions, and new OS releases. Otukan tests its protection against them and tells your team what changes.
- Protection changes. A new control, a tuned response or a new version of Otukan’s protection, approved by your owners and recorded with the build.
Rollback
App stores do not roll back a binary. A bad release is fixed by stopping the rollout and shipping a new build with a higher version number: Google Play staged rollouts can be halted, and App Store phased releases can be paused. Because every protected build records its profile version, the last known good build and its profile are on hand, and the fix goes through the same protection and tests. Where your design allows it, a control’s response can be relaxed from your server without a new release.
Support
Otukan’s engineers support your team for the platforms, toolchains and frameworks agreed for your apps, with Android and iOS listed separately. When a protected build misbehaves, your team shares the profile version, the step logs and the device details, never production credentials or user data.
For how integration fits the wider protection model, return to mobile app security.