Your team controls signing material, from start to finish. Otukan’s protection is applied as part of producing the release build, before any signature, and your own pipeline then signs the protected artefact with your identity: your Android upload key or app signing key, or your Apple distribution certificate and provisioning profiles. Otukan never asks you to upload keystores, certificates, passwords or store credentials. Where a store re-signs after upload, as Google does under Play App Signing and Apple does for App Store builds, Otukan’s integrity checks expect the certificate users actually receive. Android and iOS are planned separately, and recovery decisions stay with your release owner.
Key ownership
Signing proves who published an app. Whoever holds the key can publish in your name, so the first question for any protection vendor is where your keys go.
Signing modes
| Mode | Who holds the signing key | How Otukan fits |
|---|---|---|
| Local signing in your pipeline | Your CI secret store or signing service | The standard model: protect, then your job signs |
| Play App Signing on Android | You hold the upload key; Google holds the app signing key | Your job signs with the upload key; checks expect Google’s certificate |
| Android outside Google Play | You hold the app signing key | Your job signs; checks expect your certificate |
| App Store and TestFlight on iOS | You hold the distribution certificate; Apple processes the build | Your job signs; checks rely on properties that survive Apple’s processing |
| Other Apple distribution paths | You hold the relevant certificate and profiles | Planned with you per path |
| Uploading credentials to a vendor | The vendor holds a copy of your key | Not needed: Otukan does not take custody of keys |
Handing a keystore or certificate to a third party so it can sign on your behalf widens who can publish your app. Otukan is built so that the protection step and the signing step are separate jobs with separate permissions.
Where the secrets live
Keep signing material in one place, used by one job. Store the keystore or certificate in your CI secret store or a dedicated signing service, scope it to the signing job only, and keep a record of who can read it. The Otukan step needs none of it, so there is nothing to grant.
Which stage modifies the app
A signature only means something if nothing changes the app after it. Map every stage that alters the binary, and make sure signing comes after the last one you control.
| Stage | Changes the app? | Owner |
|---|---|---|
| Compile and link | Yes: produces the release binary | Your toolchain |
| Protect | Yes: applies the approved protection profile | Otukan step, in your pipeline |
| Sign | Adds your signature; no further code changes | Your signing job |
| Store processing | Google Play generates device-specific APKs from your app bundle and signs them; Apple re-signs and encrypts App Store builds | Google or Apple |
| Install | No | The user’s device |
Two rules follow. First, protection belongs before signing, because any change after signing breaks the signature. Second, the only changes after your signature should be the store’s own, which Otukan’s integrity checks already account for.
Artefacts to keep per release
- the signed release artefact and the certificate fingerprint used
- R8 mapping files and native debug symbols on Android, dSYM files on iOS
- the protection profile version applied to that build
- the store’s record of the delivered certificate, where one applies
These let you prove later which identity signed which protected build. For the full release record, see release evidence and auditability.
Recovery
Certificate and key changes
On Android, a lost or compromised upload key can be reset through Play Console, and Play also offers an app signing key upgrade. Apps signed outside Google Play can rotate keys with APK Signature Scheme v3. On iOS, distribution certificates expire and are renewed through your Apple Developer account. Whatever changes, tell Otukan’s engineers before the release that uses it, so integrity expectations match the new identity.
Access revocation
When someone leaves or a pipeline is retired, remove their access to the signing secret, the Apple Developer team and Play Console, and rotate any shared secret they could read. On iOS, revoking an in-house distribution certificate stops apps signed with it from launching, so plan that step carefully. The Otukan step holds no signing access, so it adds nothing to revoke.
Failed releases
A store may reject an upload signed with the wrong identity. A certificate change that was not planned can also make integrity checks flag genuine installs. Otukan reports those signals per app version, so a staged rollout shows the problem early. Halt the rollout, fix the signing or the profile, and ship a new build with a higher version number.
Platform detail is covered on Android app security and iOS app security. Where signing sits among the other pipeline stages is covered on mobile DevSecOps.