Evaluate a protection lifecycle with three questions: who may change protection, in what order a protected build moves towards release, and what happens when a stage fails. Otukan answers all three inside the build and release pipeline you already run, for Android and iOS apps built natively or with Flutter or React Native. The protection step works with narrow access, each handoff has an owner and an entry condition, and every build is pinned to a known profile and Otukan version. This page covers authority, sequence and day-to-day operations; toolchain version support is agreed per app.
Authority
Service identity and permissions
Protection is a pipeline job, so it deserves the same scrutiny as any job that touches a release. Otukan’s protection step runs under its own service identity, separate from the identities that build, sign and publish. It holds the smallest set of rights that lets it do its work.
| Actor | May do | May not do |
|---|---|---|
| Protection step identity | Read the unsigned release artefact and the approved profile; write the protected output and its log | Read signing keys, publish to a store, change source code, read production data |
| Profile approvers (your security and product owners) | Approve a new profile version or reject it | Bypass the pipeline to push a build |
| Release owner | Sign, test and submit the protected build | Change the approved profile inside a release run |
| Otukan’s engineers | Propose profile versions and read logs you share | Access your pipeline, keys or store accounts |
Otukan’s engineers write this access list down with your platform team before the first protected release, so a reviewer can compare what was agreed with what the pipeline actually grants.
Artefact inputs and secret handling
The step takes two inputs: the release artefact your build produced and the profile version your owners approved. It needs no application secrets. API keys and private credentials belong on your server, not in the app, and the protection step neither reads nor stores them. Pipeline tokens that the step itself uses are scoped to its job and live in your secrets store, not in the repository.
Sequence
A protected build passes through gated handoffs. Each stage starts only when the previous one has left the record it needs.
| Stage | Entry condition | Owner | Hands on |
|---|---|---|---|
| Protect | Release artefact built; profile version approved | Your pipeline, running the Otukan step | Protected artefact, profile version, step log |
| Sign | Protection finished without errors | Your release owner | Signed, protected build |
| Test | Signed build available | Your QA team | Results for install, update, sign-in and sensitive flows |
| Evidence | Tests recorded | Your release owner | One release record linking all of the above |
| Release | Record complete and approved | Your release owner | Staged or phased rollout |
On Android with Play App Signing, the key your team uploads with is not the key users receive; Google re-signs the app. Otukan sets up its integrity checks for the app signing certificate that reaches devices, not the upload key. Signing always follows protection, because any change to a signed artefact invalidates its signature. On iOS, your distribution certificate and provisioning profile sign the protected build as they sign releases today.
The records produced along this path are described on release evidence and auditability.
Operations
Failures and retries
Otukan’s protection step fails closed. If it cannot apply the approved profile, the release build stops and the log states which input or setting caused it, so no unprotected artefact reaches signing. A retry uses the same artefact and the same profile version, so a successful re-run applies exactly the protection that was approved, and the log keeps both attempts.
Versioning
Two versions travel with every build: the profile version, which your owners control, and the Otukan protection version, which your pipeline pins. Neither changes silently. A profile revision follows what production signals show, for example a response that proved too strict for one flow. An Otukan upgrade is handled like a toolchain upgrade, on a branch and a release candidate, before it becomes the default.
Rollback
Stores do not take a binary back. If a protected release misbehaves, your release owner halts the Google Play staged rollout or pauses the App Store phased release, then ships a new build with a higher version number. Because every build names its profile and Otukan version, the last known good pair is on hand and goes through the same gates. Where your design allows it, a control’s response can be relaxed from your server while the fix is prepared.
For how the pieces fit together, return to mobile app security.