La respuesta corta
Las llaves de firma de una app son de la empresa, no de quien la programa. Y no es una cuestión de principios: es que quien controla el certificado controla si la app puede actualizarse, y en algunos casos si puede siquiera ejecutarse.
En Apple, el certificado de distribución pertenece al equipo, y solo puede haber uno de cada tipo por equipo. En Android, si usas Play App Signing la llave importante la custodia Google y tú te quedas con una de subida, que es reemplazable. Son dos modelos muy distintos y conviene entender los dos antes de firmar un contrato de desarrollo.
Apple: un solo certificado de distribución por equipo
Es el dato que más consecuencias tiene y el que menos se conoce. Los certificados de desarrollo pertenecen a personas —de hecho se nombran con el equipo del desarrollador, tipo "Gita Kumar (Work Mac)"—, pero los de distribución pertenecen al equipo, y Apple solo permite uno de cada tipo de certificado de distribución por equipo. La única excepción son los Developer ID, de los que sí puede haber varios.
De ahí se derivan dos cosas prácticas:
- Si alguien regenera el certificado de distribución, afecta a todo el equipo, no solo a su máquina.
- La llave privada asociada es el activo real. Apple es explícito: hay que mantenerla segura y no compartirla fuera de la organización.
Y quién puede tocarla no es arbitrario:
| Rol | Crear certificados de desarrollo | Crear certificados de distribución | Revocar |
|---|---|---|---|
| Account Holder | Sí | Sí | Sí |
| Admin | Sí | Sí | Sí |
| Resto de roles | Solo los propios | No | No |
Traducido al contrato: solo el Account Holder y los Admin pueden crear o revocar certificados de distribución. Si tu agencia es el Account Holder de tu cuenta, tu agencia decide si tu app se puede publicar. No hay matices ahí.
Lo que pasa cuando un certificado caduca o se revoca
Esta tabla es la que conviene tener delante al negociar un traspaso, porque no todos los certificados fallan igual de mal:
| Certificado | Al caducar o revocarse |
|---|---|
| Push (APNs) | No se pueden enviar notificaciones |
| Apple Pay | Las transacciones fallan |
| Pass Type ID (Wallet) | No se pueden firmar ni actualizar pases; si se revoca, los pases existentes dejan de funcionar |
| Distribución App Store | No se pueden subir versiones nuevas; las apps ya publicadas siguen bien si la membresía está vigente |
| Distribución In-House | Los usuarios no pueden ejecutar la app firmada con el certificado revocado |
| Developer ID Application | Al caducar, lo ya instalado sigue funcionando; al revocarse, se bloquea la instalación |
Las dos filas en negrita son las que convierten un problema administrativo en una incidencia de negocio. Una app interna distribuida In-House cuyo certificado se revoca deja de arrancar en todos los teléfonos de la plantilla el mismo día. No es que no se actualice: es que no abre.
Por eso el vencimiento de certificados es un elemento de calendario, no una tarea de mantenimiento. Alguien tiene que tenerlo en su agenda, con nombre y apellidos.
Android: Play App Signing cambia la pregunta
En Android el modelo es distinto y, bien usado, más seguro. Con Play App Signing hay dos llaves:
- Llave de subida (la tienes tú): en un keystore de Java (
.jkso.keystore), RSA de 2048 bits o más. Firmas el bundle con ella antes de subirlo, y Google la usa para verificar tu identidad. - Llave de firma de la app (la custodia Google): Google genera por defecto RSA de 4096 bits, y es la que aplica al firmar los APK que llegan al dispositivo del usuario.
Y aquí está la diferencia que importa:
| Qué pierdes | Consecuencia |
|---|---|
| La llave de subida | Recuperable. Se pide un reinicio enviando un certificado nuevo y el motivo |
| La llave de firma de la app, si la gestionas tú sin Play App Signing | No se puede reiniciar. Se acabó |
Esa segunda fila es la razón por la que Play App Signing, aunque no sea obligatorio, es lo recomendable. Las apps nuevas se inscriben automáticamente, hoy con firma híbrida preparada para criptografía post-cuántica; las existentes pueden migrar. Y si la llave se compromete o se queda corta, hay una actualización anual de llave, con la particularidad de que a partir de Android T se fuerza el uso estricto de la llave actualizada mientras que las versiones anteriores siguen reconociendo la antigua con validación adicional de Play Protect.
Sin Play App Signing, perder el keystore es perder la app: no se puede publicar una actualización, y los usuarios tendrían que desinstalar e instalar otra ficha distinta. Es el fallo más caro y más evitable del ecosistema Android.
El reparto correcto de custodia
- La cuenta de desarrollador, de Apple y de Google, a nombre del cliente. La agencia entra como miembro del equipo, nunca como Account Holder.
- El rol de Account Holder, en una persona de la empresa que siga ahí dentro de tres años. No en el CTO que está de salida ni en un correo personal.
- Play App Signing activado. La llave que no puedes perder, que la guarde quien tiene infraestructura para guardarla.
- La llave de subida, en el gestor de secretos del cliente, no en el portátil de nadie ni en un repositorio.
- Un inventario con fechas de caducidad de cada certificado y un responsable por cada uno.
- Acceso de la agencia revocable en un clic, sin que eso rompa nada. Si revocar el acceso de tu proveedor rompe la app, no tienes un proveedor: tienes una dependencia.
Señales de que ya estás cautivo
Si respondes que sí a alguna, tienes un problema que se arregla mejor hoy que dentro de un año:
- La cuenta de Apple Developer está a nombre de la agencia.
- No sabes quién es el Account Holder.
- El keystore de Android está "en el repositorio" o "lo tiene el que se fue".
- No hay Play App Signing y nadie sabe dónde está la copia de seguridad del keystore.
- Nadie sabe cuándo caduca el certificado de distribución.
Los dos últimos son los que acaban en incidente. Los tres primeros son los que acaban en factura cuando quieres cambiar de proveedor — y ahí toca transferir la app a otra cuenta, con todo lo que eso arrastra.
Lo que debería estar en el contrato
Cuatro cláusulas, y ninguna es agresiva:
- Las cuentas de desarrollador son propiedad del cliente; el proveedor accede como miembro invitado.
- Toda llave y certificado generado en el proyecto se deposita en el gestor de secretos del cliente en el momento de crearse.
- El traspaso a otro equipo forma parte del alcance, con inventario de llaves, y no se factura aparte.
- Un inventario de caducidades entregado y actualizado en cada entrega.
Si un proveedor pone pegas a las cuatro, esa es la información que buscabas.
Es lo primero que miramos en una auditoría técnica de app móvil: antes que la arquitectura, quién tiene las llaves. Y es una de las conversaciones que abrimos el primer día cuando hacemos de CTO as a Service.
Fuentes primarias, consultadas el 14 de agosto de 2026: Certificates overview en la ayuda de la cuenta de Apple Developer, y Use Play App Signing en la ayuda de Google Play.
