The short answer
The signing keys for an app belong to the company, not to whoever writes the code. And that isn't a matter of principle: whoever controls the certificate controls whether the app can be updated, and in some cases whether it can run at all.
On Apple, the distribution certificate belongs to the team, and there can only be one of each type per team. On Android, if you use Play App Signing the key that matters is held by Google and you keep an upload key, which is replaceable. Two very different models, and it's worth understanding both before signing a development contract.
Apple: one distribution certificate per team
This is the fact with the most consequences and the least awareness. Development certificates belong to individuals — they're even named after the developer's machine, like "Gita Kumar (Work Mac)" — but distribution certificates belong to the team, and Apple allows only one of each distribution certificate type per team. The only exception is Developer ID, of which you can have several.
Two practical consequences follow:
- If someone regenerates the distribution certificate, it affects the whole team, not just their machine.
- The associated private key is the real asset. Apple is explicit: keep it secure and don't share it outside your organisation.
And who can touch it isn't arbitrary:
| Role | Create development certs | Create distribution certs | Revoke |
|---|---|---|---|
| Account Holder | Yes | Yes | Yes |
| Admin | Yes | Yes | Yes |
| Other roles | Own only | No | No |
Translated into contract terms: only the Account Holder and Admins can create or revoke distribution certificates. If your agency is the Account Holder of your account, your agency decides whether your app can ship. There's no nuance there.
What happens when a certificate expires or is revoked
This table is the one to have in front of you when negotiating a handover, because not all certificates fail equally badly:
| Certificate | On expiry or revocation |
|---|---|
| Push (APNs) | Notifications can't be sent |
| Apple Pay | Payment transactions fail |
| Pass Type ID (Wallet) | Passes can't be signed or updated; if revoked, existing passes stop working |
| App Store distribution | No new versions can be uploaded; published apps are unaffected while membership is valid |
| In-House distribution | Users can't run the app signed with the revoked certificate |
| Developer ID Application | On expiry, installed versions keep running; on revocation, installation is blocked |
The two bold rows turn an administrative problem into a business incident. An internal app distributed In-House whose certificate is revoked stops launching on every phone in the company on the same day. Not "doesn't update" — doesn't open.
That's why certificate expiry is a calendar item, not a maintenance task. Someone has to own it, by name.
Android: Play App Signing changes the question
Android's model is different and, used well, safer. With Play App Signing there are two keys:
- Upload key (you hold it): in a Java keystore (
.jksor.keystore), RSA 2048-bit or larger. You sign the bundle with it before uploading, and Google uses it to verify your identity. - App signing key (Google holds it): Google generates 4096-bit RSA by default, and it's what signs the APKs delivered to users' devices.
Here's the difference that matters:
| What you lose | Consequence |
|---|---|
| The upload key | Recoverable. Request a reset by submitting a new certificate and a reason |
| The app signing key, if you manage it yourself without Play App Signing | It cannot be reset. That's the end of it |
That second row is why Play App Signing, although not mandatory, is the sensible choice. New apps are enrolled automatically, today with quantum-ready hybrid signing; existing apps can migrate. And if the key is compromised or weakened, there's an annual key upgrade, with the particularity that from Android T onwards strict use of the upgraded key is enforced, while older versions still recognise the legacy key with additional Play Protect validation.
Without Play App Signing, losing the keystore means losing the app: you can't publish an update, and users would have to uninstall and install a different listing. It's the most expensive and most avoidable failure in the Android ecosystem.
The right split of custody
- The developer account, Apple's and Google's, in the client's name. The agency joins as a team member, never as Account Holder.
- The Account Holder role held by someone at the company who'll still be there in three years. Not the CTO on their way out, and not a personal email address.
- Play App Signing enabled. The key you can't afford to lose should be held by someone with the infrastructure to hold it.
- The upload key in the client's secret manager, not on anyone's laptop and not in a repository.
- An inventory with expiry dates for every certificate, and an owner for each.
- The agency's access revocable in one click, without that breaking anything. If revoking your supplier's access breaks the app, you don't have a supplier — you have a dependency.
Signs you're already locked in
If you answer yes to any of these, you have a problem that's cheaper to fix today than in a year:
- The Apple Developer account is in the agency's name.
- You don't know who the Account Holder is.
- The Android keystore is "in the repo" or "with the person who left".
- There's no Play App Signing and nobody knows where the keystore backup is.
- Nobody knows when the distribution certificate expires.
The last two end in an incident. The first three end in an invoice when you want to change supplier — and then you're transferring the app to another account, with everything that drags along.
What should be in the contract
Four clauses, none of them aggressive:
- Developer accounts are the client's property; the supplier accesses as an invited member.
- Every key and certificate generated during the project is deposited in the client's secret manager at the moment of creation.
- Handover to another team is part of the scope, with a key inventory, and isn't billed separately.
- An expiry inventory delivered and kept up to date with each release.
If a supplier objects to all four, that's the information you were looking for.
It's the first thing we check in a technical audit of a mobile app: before the architecture, who holds the keys. And it's one of the conversations we open on day one when acting as CTO as a Service.
Primary sources, consulted on 14 August 2026: Certificates overview in Apple Developer Account Help, and Use Play App Signing in Google Play Help.
