Evaluate build and release integration by asking three questions of any protection step. What authority does it hold: which identity it runs as, what it can read and which secrets it touches? Where does it sit in the sequence relative to signing, testing and evidence? And how does it behave when something goes wrong: failure, retry, versioning and rollback? Otukan answers each one plainly. Protection runs as one scoped step inside the pipeline you already operate, for Android and iOS apps including Flutter and React Native, it never touches signing keys or store credentials, and it fails loudly.
Authority
A protection step handles your release build, so treat it like any privileged pipeline component. These are the checks worth making, and how Otukan meets each.
| Question to ask | Why it matters | Otukan’s answer |
|---|---|---|
| Which identity runs the step? | Shared or personal credentials blur accountability | A pipeline service identity you create and scope |
| What can it read? | Broad access widens what a compromised job can reach | The release inputs for this build and the approved protection profile |
| What can it write? | Write access to release channels lets a job publish | Its protected artefact and logs, in your artefact store |
| Does it need secrets? | Every secret in a job is a secret that can leak | No signing keys, certificates, provisioning profiles or store credentials |
| Where does data go? | Code and artefacts are your intellectual property | Nowhere you have not agreed |
Artefact inputs
Pin what goes in. Each Otukan run records the source commit, the toolchain and the protection profile version, so the protected artefact can be traced to exactly what produced it. On Android this sits next to your app bundle and R8 mapping file; on iOS, next to the Xcode archive and dSYM files.
Secret handling
Keep release secrets out of the protection stage entirely. Your signing identity lives with the signing job, and store credentials live with the release job. Because the Otukan step needs neither, a compromise of that stage cannot sign or publish a build.
Sequence
Order matters because each later stage should see the app your users will receive.
Protection before signing
Protection is applied together with the build. Signing follows, under your identity. On Android that means your upload key, with Google re-signing through Play App Signing, and Otukan’s integrity checks expect the certificate users actually receive. On iOS it means your distribution certificate and provisioning profile, with Apple re-signing App Store builds.
Testing the protected build
Test the build you will ship, not the unprotected one. Regression and sensitive-flow tests run on the signed, protected artefact on physical devices. For device test planning, see protected mobile app testing.
Evidence handoff
Test results join the protection logs and the profile version, forming one record per release. That record answers the auditor’s question of what was shipped and how it was protected. See release evidence and auditability for the full record.
Operations
Failures
A failed or partial protection fails the job. The pipeline stops before signing, so an unprotected build is not handed on by mistake. If your release owner needs an override, it is a recorded decision.
Retries
A retry applies the same pinned profile to the same recorded inputs, so a retry after a runner fault is safe and the protection you ship stays the same.
Versioning
Protection profiles carry versions like code. A profile change is reviewed, merged and applied to the next build, and each artefact names the version it used.
Toolchain and platform upgrades
A new Xcode, Android Gradle Plugin or framework release changes what goes into the build. Treat it like a profile change: run the protected pipeline on a branch, repeat the device tests and compare the evidence with the last release before merging. Otukan’s engineers work through these upgrades with your team, separately for each platform.
Rollback
Published binaries cannot be swapped back. Halt the rollout, fix forward with a higher version number, and rebuild from the last known good commit and profile if needed. The full path from pipeline access to planned rollback is set out on protection lifecycle. For signing detail, see app signing security.
Otukan’s engineers reproduce your pipeline with you before the first automated protected release, separately for Android and iOS. Return to mobile app security to see how integration fits the wider product.