Security and release teams plan a protection rollout in three stages. Run a pilot on a handful of builds that represent your real releases, with success criteria agreed before work starts. Map ownership inside the pipeline: who holds credentials, who changes protection policy, who tests and who signs. Then roll out with failure rules, monitoring and a rollback path written down in advance. The plan below treats Android and iOS as separate release tracks, including Flutter and React Native apps, because stores, signing and tooling differ. It feeds your change-management process rather than replacing it.
How Otukan fits a pipeline is covered on mobile DevSecOps. The full set of evaluation aids is on solution guides.
Pilot plan
A pilot proves the protection step on builds you actually ship. Keep it narrow, but make it honest.
Choose representative builds
- One app per framework you release: native Android, native iOS, Flutter, React Native.
- The release variant, built by the pipeline, not a developer’s machine.
- The build with the most native code and the most third-party SDKs, because it is the likeliest to surface conflicts.
- Every flavour, market variant or white-label copy that ships from the same code.
- Any app extension, widget or companion target that ships inside the iOS archive.
Agree success criteria
| Criterion | Evidence | Owner |
|---|---|---|
| The protected build passes the pipeline | Job logs from your CI/CD system | Release engineering |
| Crash traces stay readable | A test crash translated to source lines | Mobile engineering |
| Key journeys behave as before | Regression run on the protected build | QA |
| Detections fire where expected | Authorised lab reproduction per platform | Security |
| Store submission is accepted | Upload to internal testing and TestFlight | Release engineering |
How Otukan answers. Otukan’s engineers join the pilot and map, with yours, where the protection step sits in your pipeline for each platform. The step fits the CI/CD system you already use, does not send your code or artefacts anywhere you have not agreed, and every protected build records the commit, toolchain and protection profile version, with logs you keep.
Pipeline ownership
Protection adds one stage to your pipeline and several decisions to your team. Assign each before the pilot ends.
Credentials
- Where do the Android upload key and the iOS distribution certificate and provisioning profiles live, and who can use them?
- Does the protection stage need any secret beyond its own configuration?
- Is Play App Signing in use, so that Google Play holds the app signing key and your team holds the upload key?
Policies
- Is the protection profile stored in version control next to the app code?
- Who approves a change to protection settings, and is that review recorded?
Testing and signing
- Does the regression suite run on the protected artefact, not the unprotected one?
- Does signing happen after protection, with the same controls as today?
| Task | Security | Mobile engineering | Release engineering |
|---|---|---|---|
| Own the protection profile | Approves | Proposes changes | Deploys |
| Hold signing credentials | Audits access | No access needed | Owns |
| Run protected regression | Reviews results | Fixes issues | Schedules |
| Receive runtime signals | Owns response rules | Adds context | Reports per release |
How Otukan answers. The Otukan step never needs your signing keys or store credentials; signing stays exactly where it is today. The same inputs and protection profile produce an equivalent protected artefact, and R8 mapping files, native debug symbols and dSYMs remain usable for crash reporting.
Rollout
Decide how you will stop before you decide how you will start.
Failure decisions
- If the protection stage fails, does the job fail, or could an unprotected build slip through?
- Who can approve an urgent fix release, and does it follow the same protected path?
Monitoring
- Which runtime signals, crash reports and support tickets will you compare against the previous release?
- Will you release through a Google Play staged rollout and an App Store phased release?
Rollback
A published version cannot be pulled back from devices that installed it. Rollback means halting the Google Play staged rollout or pausing the App Store phased release, keeping the previous protected build ready and shipping a corrected build. On iOS, a phased release only paces automatic updates: anyone can still download the new version manually from the App Store, so plan the fix as if every user may have it.
- Release to internal testers and TestFlight groups.
- Start a staged rollout on Google Play and a phased release on the App Store.
- Compare signals, crashes and support volume with the prior release.
- Widen the rollout, or halt it on Google Play, pause it on the App Store and ship the corrected build.
How Otukan answers. A failed or partial Otukan protection returns a failing exit code and fails the job, so an unprotected build cannot slip into the release by accident. Runtime signals reach your backend per release for monitoring, and where the design allows, a control’s response can be relaxed from your server without a new build.
Testing practice for protected builds is covered on protected mobile app testing.