Notificaciones push en iOS: configuración y pruebas para apps

Configurar notificaciones push en iOS requiere coordinar la aplicación, las credenciales de Apple, el registro del dispositivo y el sistema de envío. Una notificación recibida en desarrollo es un primer resultado; para preparar la puesta en producción también hay que comprobar el paquete distribuido, la presentación del aviso y la acción tras pulsarlo.

Esta guía recorre ese proceso con una app nativa y EngageLab AppPush. El equipo de desarrollo prepara la integración; producto y operaciones pueden participar en las pruebas desde la consola. Para quien solo necesita cambiar los ajustes del teléfono, está la guía para activar las notificaciones push en iPhone .

Qué necesita una app iOS para recibir notificaciones push

Una notificación remota parte del servidor o de una plataforma de envío y pasa por Apple Push Notification Service (APNs) . El destino se identifica mediante un token asociado a la app y al dispositivo. Una notificación local, en cambio, se programa en la propia aplicación.

Antes de configurar el envío conviene asignar responsables y reunir estas comprobaciones:

La ruta descrita utiliza AppPush de EngageLab para integrar el SDK y enviar desde la consola. La primera prueba será un aviso visible de un pedido ficticio. Las imágenes y los destinos internos se añadirán cuando el envío básico esté comprobado.

Preparar la app, las credenciales y el entorno de APNs

Comprobar el Bundle ID, la capacidad y la firma

En Xcode, el target de la app debe tener habilitada la capacidad Push Notifications . En Apple Developer también debe estar activado el servicio para el App ID correspondiente. El Bundle ID tiene que coincidir con el configurado en la plataforma.

Después hay que comprobar el permiso de firma aps-environment del paquete que se va a probar. Xcode lo determina a partir del perfil de aprovisionamiento. Si falta, se revisa la firma y se genera una compilación corregida; cambiar únicamente un campo en la consola no modifica una app ya instalada.

Elegir una clave .p8 o un certificado y revisar su alcance

Las credenciales autentican al sistema que envía a APNs. Hay dos rutas:

• Clave .p8: se crea en la sección Keys de Apple Developer, con APNs habilitado. Se registran el Key ID, el Team ID y el alcance autorizado.
• Certificado .p12: se genera el certificado de push para la aplicación y se exporta desde Acceso a Llaveros con su clave privada. Hay que controlar su caducidad y los entornos que admite.

Apple incorporó claves limitadas por entorno y por tema de push , este último asociado al Bundle ID. Por eso, la extensión .p8 no demuestra que una clave sirva para todas las apps y ambos entornos. Las claves anteriores conservan su alcance; antes de crear una nueva, hay que comprobar también que la plataforma admite la modalidad elegida.

La guía de credenciales de EngageLab sitúa la configuración en App Settings > iOS Authentication : para tokens, se carga el archivo y se indican Key ID, Team ID y Bundle ID; para certificados, se carga el .p12. El Bundle ID debe revisarse antes de guardar, porque su cambio posterior está restringido. Los secretos permanecen en el backend o en la configuración protegida del proveedor.

Relacionar el entorno de la app con la configuración de envío

La documentación de Apple distingue desarrollo y producción mediante aps-environment . TestFlight utiliza producción. Esta correspondencia debe verificarse sobre el paquete firmado:

Además, EngageLab dispone de un modo de prueba con un AppKey distinto . Ese espacio de trabajo y el entorno de APNs son configuraciones diferentes. El registro de la prueba debe incluir el AppKey, el valor firmado, el ajuste del SDK y el alcance de la credencial.

Integrar EngageLab AppPush y registrar el dispositivo

Configurar el SDK y solicitar los permisos necesarios

La guía de integración de iOS documenta la instalación de MTPush y su inicialización con el AppKey. La configuración debe corresponder al proyecto y al entorno registrados en el paso anterior.

Hay dos operaciones distintas: solicitar permiso para mostrar avisos y registrar la app en APNs. En Swift, estas llamadas de Apple ilustran la separación:

import UIKit
import UserNotifications

@MainActor
func registrarEnAPNs() {
    UIApplication.shared.registerForRemoteNotifications()
}

func solicitarAvisos() {
    UNUserNotificationCenter.current().requestAuthorization(
        options: [.alert, .sound, .badge]
    ) { autorizado, error in
        if let error = error {
            print("Error de autorización: \(error.localizedDescription)")
            return
        }
        print("Avisos autorizados: \(autorizado)")
    }
}

El registro se inicia al arrancar la app; el permiso se solicita cuando el usuario entiende su utilidad, por ejemplo, al activar el seguimiento de pedidos. Este fragmento explica las llamadas del sistema: la inicialización del SDK y sus callbacks se incorporan según la guía. Si el SDK ya gestiona esas llamadas, se mantiene un único flujo.

Comprobar el token de APNs y el registrationID

Tras registrarse, iOS entrega el token en application(_:didRegisterForRemoteNotificationsWithDeviceToken:) . La API Objective-C de EngageLab documenta registerDeviceToken: para comunicarlo al SDK. Si falla el registro, el callback de error ayuda a revisar la red y la firma; iniciar sesión en el SDK por sí solo no acredita la conexión de APNs.

La API del SDK permite obtener el registrationID mediante un callback. Conviene distinguir los identificadores:

• Bundle ID: identifica la aplicación ante Apple.
• AppKey: vincula el SDK con la aplicación de EngageLab.
• Token de APNs: identifica el destino de la app en el dispositivo para Apple.
• registrationID: identifica el dispositivo registrado para dirigir el envío en EngageLab.
• ID de usuario: identifica la cuenta del negocio; su asociación con dispositivos debe gestionarse aparte.

Antes de enviar, se comprueban el registro de APNs, la comunicación del token al SDK y un registrationID válido del entorno seleccionado. El token puede cambiar: se debe actualizar con el valor que entrega iOS, sin reutilizar indefinidamente una copia antigua.

Enviar la primera notificación desde la consola

Seleccionar iOS y un destinatario de prueba

Con el SDK y las credenciales preparados, la ruta documentada para crear una notificación es Push > Notificaciones in-app . Se comprueban la aplicación, el entorno de trabajo y la plataforma iOS.

En la audiencia se introduce el registrationID obtenido del dispositivo de pruebas. Así se puede relacionar el resultado con una instalación concreta. Para este primer envío no se utiliza la opción de difusión a todos los usuarios.

Definir el contenido y comprobar la acción al abrir

Este ejemplo hipotético permite revisar el mismo caso entre desarrollo y operaciones:

Se configura como aviso visible, con envío inmediato. Antes de confirmar se revisan el contenido, la audiencia y las opciones de iOS. Si se va a comprobar la estadística de Impressions, también deben estar preparados la extensión y el ajuste descritos en el siguiente apartado.

La consola ofrece Vista previa para revisar los parámetros y Confirmar para crear la tarea. Tras el envío se conservan:

• Compilación instalada, AppKey y entorno APNs.
• Destinatario de prueba e identificador del mensaje.
• Hora de envío, estado de la app y permiso de avisos.
• Resultado en el teléfono y registros disponibles.

Una vez comprobada la apertura básica, se puede probar el acceso al pedido. El cliente debe interpretar los datos del mensaje y resolver la navegación; escribir un identificador en un campo no crea esa lógica. Las notificaciones push enriquecidas se incorporan después, con sus propias pruebas de contenido.

Comprobar la recepción, la presentación y el clic

Probar los estados de la app y el comportamiento esperado

La prueba necesita un resultado esperado por escenario. En primer plano, la app decide cómo tratar la notificación mediante su delegate; la ausencia de un banner no basta para concluir que el mensaje no llegó.

Para separar fallos de presentación y de envío, se anotan también los modos de concentración y el resumen de notificaciones. Si se prueba una desconexión temporal, se registra la caducidad configurada: el almacenamiento de APNs tiene condiciones y no garantiza recuperar todos los avisos al reconectar.

Interpretar los resultados según la instrumentación disponible

Los informes de AppPush permiten consultar etapas y resultados por mensaje, plataforma y canal. Para analizarlos hay que separar:

• Envío: el resultado que registra la plataforma para la solicitud.
• Confirmación técnica de recepción: la señal disponible desde el dispositivo o la integración.
• Presentación: lo que muestra realmente iOS.
• Clic: la interacción registrada al pulsar el aviso.

En iOS, EngageLab obtiene Impresions del reporte de entrega de su Notification Service Extension . La integración requiere el SDK de la extensión, el AppKey correspondiente y mutable-content . Si esa instrumentación no está preparada, la ausencia del contador no demuestra que el teléfono no recibiera el mensaje.

Ese reporte tampoco acredita que una persona haya leído el aviso. Para cerrar la prueba se contrastan el mensaje, el destinatario, la hora, la observación en el dispositivo y los callbacks. La conversión del pedido se mediría como otro evento del negocio.

Qué revisar si las notificaciones no llegan a la app de prueba

La investigación comienza en el primer punto sin evidencia. Repetir envíos sin comprobar la instalación, el entorno y los identificadores puede ocultar el origen del fallo.

Apple define BadDeviceToken como un token no válido y pide comprobar su correspondencia con el entorno. Esa respuesta no equivale a que el usuario haya rechazado los avisos. Si la plataforma muestra otro código, hay que consultar su propia definición antes de asignarle una causa.

Cuando el problema solo aparece en una red corporativa, el equipo de sistemas puede seguir la guía de conexión con APNs de Apple . El diagnóstico debe incluir la hora del fallo y la red utilizada.

Antes de ampliar la audiencia, conviene cerrar la matriz de pruebas y asignar quién mantiene las credenciales, actualiza los registros de dispositivos y revisa errores. El tratamiento de reintentos debe distinguir fallos temporales de configuraciones inválidas. Una recepción aislada no sustituye esa entrega operativa.

Preguntas frecuentes

¿Qué revisar si las notificaciones funcionan en desarrollo, pero no en mi app en TestFlight?

Primero, la correspondencia entre el paquete de TestFlight, APNs de producción y la configuración de envío. Después, el AppKey y el registro del dispositivo obtenidos con esa instalación. El nombre «prueba» de TestFlight no implica usar APNs sandbox ni el AppKey de prueba de EngageLab.

¿Se puede usar Firebase para enviar notificaciones a una app iOS?

Sí. Firebase Cloud Messaging ofrece una ruta de integración para plataformas Apple que utiliza APNs. Tiene su propio SDK y sus tokens de registro. Para seguir esa ruta debe utilizarse la documentación oficial de Firebase , sin mezclar sus identificadores con los de EngageLab.

¿Por qué una notificación silenciosa de actualización en segundo plano no activa siempre la app?

Porque iOS trata esas actualizaciones como trabajo de baja prioridad y no garantiza su entrega . No deben sostener una operación que exija ejecución inmediata. Aquí «silenciosa» describe una actualización en segundo plano, no el ajuste de sonido de un aviso visible.

¿Qué diferencia hay entre las notificaciones de una app y las notificaciones web en iOS?

La integración nativa requiere una app instalada y su configuración de APNs. Web Push parte de una suscripción web y tiene requisitos propios de navegador y aplicación web; en iOS también utiliza APNs. Configurar el SDK de AppPush no activa por sí mismo las notificaciones de un sitio.