Cada integración de notificaciones push de iOS comienza en el mismo punto: demostrar al servicio de notificaciones push de Apple que tienes permiso para enviar mensajes a los usuarios de tu aplicación. Apple te ofrece dos formas de hacerlo: una clave de autenticación de APNs (.p8) o un certificado de APNs (.p12), y la diferencia entre ellas es la diferencia entre una credencial que configuras una vez y otra que renovarás cada año, a menudo en el peor momento posible.
Esta guía explica cómo funciona realmente la autenticación de APNs, cuándo usar una clave .p8 en lugar de un certificado .p12 y el puñado de errores que se remontan a haber hecho esto mal.
Cómo funciona la autenticación de APNs
Cuando tu proveedor de notificaciones push —PushEngage, o tu propio servidor— envía una notificación, se conecta a la API del proveedor de APNs de Apple y debe demostrar dos cosas: que está autorizado a enviar en tu nombre y que tiene permiso para dirigirse al ID de paquete de tu aplicación (el "tema" en términos de APNs). La clave .p8 y el certificado .p12 son solo dos formas diferentes de demostrarlo.
El lado del dispositivo es independiente. Tu aplicación se registra en APNs y recibe un token de dispositivo; esa parte nunca cambia, independientemente de la credencial que utilice tu proveedor. La autenticación es puramente una preocupación del servidor a Apple, por lo que puedes cambiar de método sin tocar el binario de tu aplicación.
La clave de autenticación .p8 (usa esta)
La .p8 es una clave de firma de tokens. Tu proveedor la utiliza para generar tokens web JSON de corta duración que autentican cada conexión a APNs. Sus propiedades la convierten en la opción predeterminada para casi todo el mundo:
- Nunca caduca. Sin renovaciones anuales, sin interrupciones de notificaciones en una fecha olvidada.
- Una clave cubre todas las aplicaciones de tu cuenta de desarrollador. Si publicas una segunda aplicación, la misma clave la autenticará.
- Funciona tanto para entornos de desarrollo como de producción; no hay pares de certificados de sandbox/producción.
- Se transmite como tres valores: el archivo .p8 en sí, el ID de clave de 10 caracteres y tu ID de equipo.
Dos cosas que debes saber antes de crear una. Apple te limita a dos claves de APNs activas por cuenta, por lo que las organizaciones grandes deben tratar la creación de claves como un acto deliberado, no como un hábito por proyecto. Y el archivo .p8 solo se puede descargar una vez, en el momento de la creación; guárdalo en un lugar donde tu equipo pueda encontrarlo, porque Apple no te lo volverá a dar.
El certificado .p12 (la ruta heredada)
El .p12 es un certificado de cliente TLS, exportado de Acceso a Llaveros después de que Apple lo emite. Autentica la conexión en sí en lugar de firmar tokens. Todavía funciona, y algunas políticas de seguridad empresariales todavía lo requieren, pero sus limitaciones son la razón por la que Apple dirige las nuevas integraciones hacia la clave:
- Caduca cada año. La causa más común de fallos repentinos y totales de las notificaciones push es un certificado de APNs que ha caducado silenciosamente.
- Está limitado a una sola app. Cada ID de bundle necesita su propio certificado, y cada certificado necesita su propio calendario de renovación.
- Requiere un Mac. El proceso de exportación de la solicitud de firma y el Keychain no tiene una ruta solo para el navegador.
¿Cuál deberías usar?
| Clave de autenticación .p8 | Certificado .p12 | |
|---|---|---|
| Expira | Nunca | Cada 12 meses |
| Ámbito | Todas las apps de la cuenta | Un ID de bundle |
| Entornos | Desarrollo + producción | Separado o combinado por certificado |
| Creado desde | Cualquier navegador | Mac con Acceso a Llaveros |
| Límite de cuenta | 2 claves activas | Pares por app |
| Usar cuándo | Casi siempre | La política requiere certificados |
La respuesta honesta: usa la clave .p8 a menos que una política de seguridad te obligue a usar la ruta del certificado. Menos partes móviles, nada que renovar, una credencial para toda tu cartera.
Crear una clave .p8 en tres minutos
- En tu cuenta de desarrollador de Apple, ve a Certificados, Identificadores y Perfiles → Claves y registra una nueva clave.
- Asígnale un nombre, activa la casilla Servicio de notificaciones push de Apple (APNs) y continúa.
- Descarga el archivo .p8 (recuerda: una sola oportunidad) y anota el ID de clave que se muestra en la pantalla de confirmación y tu ID de equipo de la página de membresía de la cuenta.
- Sube los tres valores a tu proveedor de push. En PushEngage, esto se hace en una sola pantalla en la configuración de tu app; la guía de credenciales APNs te lo explica con capturas de pantalla.
Los errores que esto explica
Una sorprendente cantidad de tickets de "push está roto" son problemas de credenciales disfrazados. Los sospechosos habituales:
- BadDeviceToken — estás enviando el token de una aplicación creada en sandbox a través del entorno de producción, o viceversa. Las compilaciones de depuración de Xcode se comunican con el sandbox; las compilaciones de TestFlight y App Store se comunican con producción.
- TopicDisallowed — la credencial no cubre el ID de paquete al que te diriges. Típico de certificados .p12 por aplicación y una configuración copiada y pegada.
- Fallo repentino de entrega del 100% — un .p12 caducado. Comprueba la fecha de caducidad del certificado antes de comprobar cualquier otra cosa.
- InvalidProviderToken — una clave .p8 revocada, o el par incorrecto de Key ID/Team ID junto con un archivo válido.
Dónde encaja esto en tu integración
La credencial de APNs es el primer paso de una única sesión de configuración. Sube el .p8 a PushEngage una vez, y todo lo que siga — la integración con el SDK de iOS 1.0, los rich media a través de tu extensión de notificaciones, las campañas activadas y la entrega en sí — se ejecutará contra ella sin más ceremonias. Si vienes de Firebase, la misma clave que le diste a FCM funciona aquí, que es parte de por qué migrar de FCM en iOS es un proyecto de una tarde.
Para la capa de estrategia que viene después de la configuración, empieza con la guía de marketing push para aplicaciones. Y cuando estés listo para enviar, la guía completa de configuración de iOS te lleva desde la credencial hasta la primera campaña en menos de una hora.
