APNS: qué es, cómo funciona Apple Push Notification Service y su arquitectura

¿Qué es APNS?

Apple Push Notification Service (APNS) es el servicio propietario de Apple para enrutar notificaciones push desde el servidor de la aplicación a los dispositivos de los usuarios. A diferencia de FCM, APNS no admite Android ni otras plataformas — está completamente vinculado al ecosistema Apple.

El servicio funciona a través de una conexión TLS persistente que cada dispositivo Apple establece con los servidores APNS al iniciarse. Esta conexión se mantiene en segundo plano y se utiliza para entregar notificaciones con latencia mínima.

APNS maneja toda la infraestructura de entrega: cifrado, autenticación, priorización y retransmisión cuando el dispositivo no está disponible. El desarrollador solo necesita proporcionar un payload con el formato correcto y un token push válido.

Evolución de APNS

Originalmente, APNS funcionaba mediante un protocolo binario en los puertos 2195–2196. Desde 2015, Apple ha migrado el servicio al moderno protocolo HTTP/2, que admite multiplexación, compresión de cabeceras y notificaciones push del servidor. HTTP/2 se volvió obligatorio en junio de 2020.

¿Cómo funciona Apple Push Notification Service?

El proceso de entrega de notificaciones push a través de APNS consta de cinco etapas: registro del dispositivo, obtención del token push, envío de la solicitud por el servidor, enrutamiento de APNS y entrega al dispositivo.

• Registro — al iniciar, la app llama a registerForRemoteNotifications, el sistema se comunica con APNS
• Token — APNS devuelve un token push al dispositivo — una cadena única que identifica la app en el dispositivo
• Envío — el servidor de la app envía una solicitud POST a https://api.push.apple.com con el token y el payload
• Enrutamiento — APNS encuentra el dispositivo por el token y entrega el mensaje a través de la conexión TLS
• Procesamiento — iOS/macOS muestra la notificación o la pasa a la app según el estado

Si el dispositivo está no disponible (apagado o sin red), APNS almacena el mensaje más reciente para cada app y lo entrega cuando se restablece la conexión. La duración máxima de almacenamiento es de 4 semanas, tras las cuales se elimina el mensaje.

Autenticación en APNS: Token y Certificado

Apple admite dos métodos para autenticar el servidor de la aplicación al enviar notificaciones push. Cada método tiene sus propias características en cuanto a período de validez, gestión y facilidad de uso.

La autenticación basada en Token es el método recomendado por Apple desde 2019. Creas una única clave p8 en la Consola de Desarrolladores de Apple, la subes a tu servidor y firmas cada solicitud APNS con ella. La clave nunca caduca y funciona para todas las apps de tu cuenta.

Qué método de autenticación elegir

Para proyectos nuevos, la autenticación basada en Token es claramente preferible: una clave p8 para toda la cuenta, indefinida, sin vinculación con el entorno. El método basado en Certificado (.p12) todavía se usa en proyectos heredados pero requiere reemplazo anual y certificados separados para Sandbox y Production. Ten en cuenta la caducidad del certificado al planificar CI/CD.

Tipos de notificaciones push de APNS

APNS admite tres tipos de notificaciones push, que difieren en su comportamiento en el dispositivo y en los requisitos de atributos de la solicitud. La elección del tipo depende del escenario de UX y la urgencia del mensaje.

• Alert — notificación estándar con título, texto y botones de acción opcionales
• Background — entrega silenciosa de datos (push silencioso) sin mostrar al usuario, manejado en application:didReceiveRemoteNotification
• VOIP — tipo especial para aplicaciones VoIP (PushKit), se entrega inmediatamente incluso cuando la app está cerrada

Para notificaciones Background, debes especificar la clave content-available: 1 y establecer la prioridad en 5 (entrega eficiente energéticamente). El sistema puede limitar la cantidad de notificaciones en segundo plano si la app no las procesa oportunamente.

Configuración de prioridad de entrega

APNS admite dos valores de prioridad: 10 (entrega inmediata) y 5 (eficiente energéticamente). Para notificaciones alert, usa 10 — el usuario debe recibirlas de inmediato. Para notificaciones background, usa 5 — el sistema puede retrasar la entrega para ahorrar batería. Una prioridad incorrecta para background puede provocar el rechazo de APNS.

Formato de carga útil de APNS

APNS acepta payload en formato JSON con un tamaño máximo de 4 KB para notificaciones normales y 5 KB para VOIP. El payload contiene el diccionario obligatorio aps con configuraciones de visualización y campos personalizados opcionales.

{
    "aps": {
        "alert": {
            "title": "Nuevo mensaje",
            "body": "Tienes 3 chats no leídos"
        },
        "badge": 3,
        "sound": "default",
        "category": "message_category",
        "thread-id": "chat_room_42"
    },
    "customData": {
        "chatId": "42"
    }
}

La clave thread-id agrupa notificaciones en el Centro de Notificaciones de iOS. La clave category vincula la notificación con una UNNotificationCategory para mostrar botones de acción. Sin estas claves, todas las notificaciones se muestran individualmente.

Campos personalizados en el payload de APNS

Además del diccionario obligatorio aps, el payload de APNS puede contener cualquier campo personalizado en el nivel superior. Estos campos son accesibles para la aplicación a través del diccionario userInfo al procesar la notificación. Los datos personalizados son útiles para pasar identificadores de entidades, pantallas o enlaces. El tamaño máximo del payload es de 4 KB, por lo que evita transferir grandes volúmenes de datos a través de push; cárgalos mediante API después de abrir la notificación.

Ejemplo de envío mediante API HTTP/2

Para enviar una notificación push desde el servidor, debes ejecutar una solicitud POST al endpoint de APNS con los encabezados de autenticación correctos. A continuación se muestra un ejemplo en Node.js utilizando autenticación basada en Token.

const http2 = require("http2")
const fs = require("fs")
const jwt = require("jsonwebtoken")

const token = jwt.sign(
    { iss: "TEAM_ID", iat: Math.floor(Date.now() / 1000) },
    fs.readFileSync("AuthKey.p8"),
    { algorithm: "ES256", keyid: "KEY_ID" }
)

const payload = JSON.stringify({
    aps: { alert: { title: "¡Hola!", body: "Push de prueba" } }
})

const client = http2.connect(
    "https://api.push.apple.com"
)

const req = client.request({
    ":method": "POST",
    ":path": "/3/device/DEVICE_PUSH_TOKEN",
    "authorization": "bearer " + token,
    "apns-push-type": "alert",
    "apns-topic": "com.example.app",
    "apns-priority": "10"
})
req.end(payload)

req.on("response", (headers) => {
    if (headers[":status"] === 200) {
        console.log("Push enviado con éxito")
    }
})

Después del envío, APNS devuelve el estado HTTP 200 en caso de entrega exitosa o un código de error con descripción en el cuerpo de la respuesta. Es importante manejar los errores token-unregistered (410) — dichos tokens deben eliminarse del servidor, ya que la aplicación ha sido eliminada del dispositivo.

Errores de APNS y su manejo

APNS devuelve códigos de estado HTTP para cada solicitud de envío. La entrega exitosa devuelve el estado 200. Los errores requieren diferentes estrategias de manejo. BadDeviceToken (400) o Unregistered (410) — el token del dispositivo está desactualizado y debe eliminarse del servidor. PayloadTooLarge (413) — se ha superado el límite de 4 KB, reduce el payload.

TooManyRequests (429) — límite de solicitudes superado. APNS establece una cuota en la cantidad de envíos por segundo. Al recibir 429, implementa un retroceso exponencial (exponential backoff) y reintenta el envío. Se recomienda no superar las 100 solicitudes por segundo por conexión HTTP/2.

Errores del lado de APNS — 500 y 503 (Error Interno del Servidor / Servicio No Disponible). Son fallos temporales de la infraestructura de Apple. En tales casos, reintenta con una demora de 1 a 5 segundos, no más de 3 intentos. Los errores 5xx persistentes con un servidor completamente operativo son raros y generalmente están relacionados con problemas de conexión TLS.

Para entornos de Production, asegúrate de implementar el registro de todos los errores de APNS con el token, código de error y hora. Esto ayudará a identificar rápidamente problemas con certificados, cuotas o tokens de dispositivos específicos. Revisa regularmente las fechas de caducidad de los certificados si usas autenticación basada en Certificado.