Conectar tus cuentas de Apple y Google
Las credenciales que la plataforma usa para firmar, enviar y notificar en tu nombre, dónde generar cada una y el error clásico de cada una. Se guardan cifradas y nunca vuelven a la pantalla.
Son cuatro credenciales, y se parecen de dos en dos
| Credencial | Para qué sirve | La necesitas si |
|---|---|---|
Clave de App Store Connect (.p8 + Key ID + Issuer ID + Team ID) |
firmar y enviar el build a Apple | publicas en iOS |
Cuenta de servicio de la Play Console (.json) |
enviar versiones a Google Play | publicas en Android |
Firebase: google-services.json + cuenta de servicio (.json) |
entregar notificaciones en Android | usas push en Android |
Clave de In-App Purchase de Apple (.p8) |
verificar una compra hecha dentro de la app | vendes dentro de la app en iOS |
De ahí salen dos trampas. La cuenta de servicio de la Play Console no es la de Firebase: una publica la app,
la otra manda notificaciones, y las dos son archivos .json parecidos. Y la clave de In-App Purchase no es la
de App Store Connect: Apple las emite por separado, las dos son archivos .p8 con un bloque BEGIN PRIVATE KEY, y
por fuera son indistinguibles. Por eso la plataforma comprueba la de compras con Apple al guardarla, en lugar de
mirar su formato.
Google Play
1. Crear la app en la consola, con el identificador exacto
En la Play Console, Crear app. El nombre del paquete tiene que ser exactamente el identificador que muestra la pestaña Aplicación (hay un botón de copiar al lado).
La API de Google no crea la app. Si el paquete no está, el envío falla con Package not found, y el nombre del
paquete no se puede renombrar después.
2. Crear la cuenta de servicio
La cuenta de servicio es el usuario robot que envía las versiones. Se crea en Google Cloud y se autoriza en la Play Console. Google ya no exige vincular el proyecto de Cloud a la Play Console para usar la API, así que el camino es directo:
- en la Google Cloud Console, crea (o elige) un proyecto;
- activa la Google Play Android Developer API en él;
- en APIs y servicios → Credenciales → Crear credenciales → Cuenta de servicio, crea la cuenta. Aquí no hace falta ningún rol: el permiso que importa es el de la Play Console, en el paso siguiente;
- en la cuenta creada, Claves → Agregar clave → Crear clave nueva → JSON. El archivo se descarga al momento, y es el que subes a la plataforma.
Guarda ese .json como si fuera una contraseña: quien tenga el archivo puede publicar en tu Play Console.
3. Dar el permiso en la Play Console
Es el paso que más se olvida, y el síntoma engaña: el archivo se acepta aquí y el envío se rechaza allá.
En la Play Console, Usuarios y permisos → Invitar nuevo usuario, usa el correo de la cuenta de servicio (algo
como nombre@proyecto.iam.gserviceaccount.com), añade la app en la pestaña de permisos por app y marca:
- Publicar apps en canales de prueba;
- Publicar en producción, excluir dispositivos y usar Play App Signing, si vas a publicar en producción.
Invita. La cuenta de servicio aparece en la lista como cualquier otro usuario.
4. La huella SHA-256 (opcional)
Sirve solo para que los enlaces de tu sitio abran dentro de la app. Está en Configuración → Integridad de la app → Firma de apps. Usa la del certificado de la clave de firma de la app, no la de la clave de subida: usar la de subida es el error clásico, el valor parece correcto y la verificación de enlaces nunca pasa.
Apple
1. La clave de App Store Connect
En App Store Connect, en Users and Access → Integrations → App Store Connect API → Team Keys, pulsa Generate API Key. Ponle un nombre y elige el rol.
El rol tiene que ser Admin. App Manager no puede crear el certificado de firma, y ese fallo solo aparece al final del build, tras 20 minutos de compilación, en un mensaje sobre un certificado que no dice "rol equivocado".
Al generarla, Apple te deja descargar el archivo .p8 una sola vez. Si lo pierdes no hay recuperación: revoca la
clave y genera otra. De la misma pantalla salen los otros dos campos: el Key ID (diez caracteres, en la fila de
la clave) y el Issuer ID (un UUID, escrito encima de la lista, igual para todas tus claves).
Confundir el Issuer ID con el Key ID es el error más común, porque los dos vienen de la misma pantalla.
2. El Team ID
En developer.apple.com → Membership, arriba a la derecha, junto al nombre del equipo. Son diez caracteres. Sin él el build no puede autenticarse para firmar y falla en la nube con un error sobre un certificado.
3. Guardar el identificador
El mismo identificador del paso Marca. Es por él que Apple reconoce que una versión nueva es la misma app, y no cambia después de la primera publicación.
Notificaciones en Android: los dos archivos de Firebase
Android entrega notificaciones por Firebase Cloud Messaging, y eso exige un proyecto de Firebase tuyo. Son dos archivos distintos del mismo proyecto, y solo funcionan juntos:
| Archivo | Dónde va | Dónde descargarlo |
|---|---|---|
google-services.json |
dentro de la app, para que sepa a qué proyecto pertenece | Firebase → Configuración del proyecto → Tus apps → Android |
Cuenta de servicio (.json) |
en nuestro servidor, para autorizar el envío | Firebase → Configuración del proyecto → Cuentas de servicio → Generar nueva clave privada |
Crea la app de Android dentro del proyecto de Firebase con el mismo identificador de la app. Si los dos archivos vienen de proyectos distintos, el envío de la notificación falla con un error de remitente que no lo dice con esas palabras.
iOS no usa Firebase. Allí la entrega pasa por Apple, con la credencial que la plataforma ya crea en tu cuenta. Sin estos dos archivos, el push funciona en el iPhone y no en Android.
La clave de In-App Purchase
Solo hace falta si vas a vender una suscripción o una compra dentro de la app en iOS. En Users and Access → Integrations → In-App Purchase, pulsa Generate In-App Purchase Key. También se descarga una sola vez, y el rol exigido es Account Holder o Admin.
La guía Vender suscripciones dentro de la app explica el resto del camino.
Lo que la plataforma no puede verificar por ti
Conectar la cuenta es la mitad del trabajo. La otra mitad ocurre dentro de la consola de la tienda, y desde fuera no hay forma de ver si se hizo: si la app existe en la Play Console, si la cuenta de servicio recibió su permiso, si la clave tiene el rol Admin.
Por eso la pantalla lista esas exigencias sin bloquear el botón. Prefiere dejarte intentar y fallar con un mensaje claro a fingir que sabe algo que no sabe.