Protection becomes repeatable when it is a pipeline step like compiling or signing, and that is how Otukan runs. The Otukan step runs on every release build in the CI/CD system you already use: it applies the approved protection profile as part of producing each release artefact, keeps logs of what it did, and fails the job when protection does not complete. Your team keeps signing credentials and the release decision. This page maps where protection sits among build, test, signing and release; who owns credentials, artefacts and failure decisions; and how Otukan’s automation behaves, including rollback. Android and iOS pipelines differ, so each platform is planned on its own.
Pipeline stages
A protected mobile release passes through the same stages on every run.
- Build and protect. Compile the release variant from a tagged commit with a pinned toolchain: Gradle and the Android Gradle Plugin for Android, Xcode for iOS, and your framework’s SDK. The Otukan step applies the protection profile for this platform and stores the profile version with the build.
- Scan. Run static analysis and dependency checks on source and packages.
- Sign. Sign with your release identity: your upload key for Google Play, or your Apple distribution certificate and provisioning profile for iOS.
- Test. Install the protected, signed artefact on physical devices and run the regression and sensitive-flow tests.
- Release. Upload to the store and roll out in stages.
- Monitor. Watch crash, ANR or hang rates and Otukan’s runtime signals for the new version.
| Stage | Android specifics | iOS specifics |
|---|---|---|
| Build | App bundle, R8 mapping file and native debug symbols | Xcode archive and dSYM files |
| Sign | Upload key; Google re-signs with Play App Signing | Distribution certificate; Apple re-signs App Store builds |
| Test | Internal testing track on Google Play | TestFlight |
| Release | Staged rollout on Google Play | Phased release on the App Store |
For signing detail, see app signing security. Protected-build testing is covered on protected mobile app testing.
Ownership
Automation does not remove decisions; it makes them happen at a fixed point. Otukan’s engineers settle these with you before the first automated protected release.
| Item | What is decided | Typical owner |
|---|---|---|
| Signing keys and certificates | Where they live, who can use them, how they rotate | Release owner |
| Store and CI credentials | Scoped to the jobs that need them, stored in the CI secret store | Platform or DevOps team |
| Protection profile | Which controls apply, per platform, and who approves changes | Security and product owners, with Otukan |
| Build artefacts | Retention of protected artefacts, mapping files, dSYMs and logs per release | Mobile team |
| Failure decisions | Whether a failed protection step or test blocks the release, and who can override | Release owner, agreed with security |
Two rules keep this simple, and Otukan is built around both. The protection step never needs signing keys or store credentials. And every protected artefact is traceable to a commit, a toolchain version and a protection profile version, so any build can be explained later.
Automation you can rely on
A protection step earns its place in CI by behaving predictably. Otukan’s step does.
How the Otukan step behaves
- Defined outputs. Each run produces the protected artefact and its logs, stored where your pipeline keeps its artefacts.
- Honest exit codes. A failed or partial protection fails the job. It never passes with a warning.
- Reproducible output. The same inputs and profile produce an equivalent protected artefact.
- Readable crashes. R8 mapping files, native debug symbols and dSYMs stay usable for crash reporting.
- Your code stays yours. The step does not send your code or artefacts anywhere you have not agreed.
- Your runners. It fits the CI/CD system you already use; iOS jobs run on a macOS runner with Xcode.
Rollback behaviour
Stores do not roll back a binary. Halt the Google Play staged rollout or pause the App Store phased release, then ship a fixed build with a higher version number through the same pipeline. Because every protected build carries its profile version and logs, the last known good build is on hand, and the fix goes out with the same protection. Where your design allows it, a control’s response can be relaxed from your server without a new release. Gated handoffs, pinned versions and planned rollback are covered on how Otukan runs the protection lifecycle.
For the implementation side, see the mobile DevSecOps implementation guide. For how the pipeline fits the wider protection model, return to mobile app security.