iOS 27 rompe las notificaciones push si te saltas UISceneDelegate: la solución

Si compilas tu app contra el SDK de iOS 27 sin adoptar el ciclo de vida de UIScene, la app no arranca. Y una app que no arranca nunca se registra para push, así que tus notificaciones se apagan sin ningún crash report que apunte al push como causa. El síntoma parece un problema de entrega. En realidad es un problema de arranque.

Este es el típico bug que agarra a los equipos LATAM desprevenidos, porque las dos cosas se sienten totalmente separadas: push vive en un archivo, el arranque de la app en otro, y en tu cabeza ni se cruzan. iOS 27 las conecta. Esta guía cubre qué se rompe, la cadena exacta que apaga tus notificaciones, quién está en la zona de impacto y el checklist de migración para arreglarlo. Pushwoosh es una plataforma de engagement de clientes, y su SDK para iOS ya maneja esta transición, pero la solución de abajo aplica la uses o no.

Qué se rompe en realidad

Apple anunció en la WWDC25 que la versión posterior a iOS 26 exigiría el ciclo de vida de UIScene para cualquier app UIKit compilada con el SDK más reciente. iOS 27 es esa versión. El requisito ya está aplicado.

El disparador importa, y la mayoría de los hilos alarmistas lo entienden mal: la aplicación ocurre cuando compilas contra el SDK de iOS 27 en Xcode 27, no simplemente cuando un usuario corre tu app existente en un iPhone con iOS 27. Tu build actual, ya publicado, sigue funcionando en los teléfonos actualizados. La ruptura llega con tu próxima versión compilada en el SDK nuevo. Esa distinción te da tiempo, pero solo hasta tu próximo envío.

Esto es lo que no cambia, que es justo donde las notas alarmistas se pasan de rosca: el flujo de APNs en sí queda intacto. Sigues pidiendo autorización, sigues llamando a registerForRemoteNotifications(), y sigues recibiendo el device token en didRegisterForRemoteNotificationsWithDeviceToken. Ese callback se queda en tu AppDelegate, y en iOS 27 hoy no existe un equivalente basado en scene al que moverlo. El mecanismo de push está bien. Lo que Apple cambió es el arranque.

La cadena que apaga tu push

Cuando una app sin manifiesto de scene se compila contra el SDK de iOS 27, la falla corre en este orden:

1. UIKit exige la adopción de scene al arrancar y no encuentra ningún UIApplicationSceneManifest en tu Info.plist.
2. La app termina antes de que corra ningún método del AppDelegate.
3. Como application(_:didFinishLaunchingWithOptions:) nunca se ejecuta, registerForRemoteNotifications() tampoco se dispara.
4. Sin registro, didRegisterForRemoteNotificationsWithDeviceToken nunca se llama, así que la app nunca recibe un token de APNs.
5. Sin token, no hay entrega. Y como la app crasheó al arrancar, tus logs le echan la culpa al lanzamiento, no al pipeline de notificaciones.

La razón por la que esto te hace perder tantas horas de debugging es que el síntoma y la causa quedan lejísimos uno del otro. Ves entregas faltantes y arrancas a auditar tu proveedor de push, tus payloads, tus certificados. La falla real está 3 capas más arriba, en un archivo de manifiesto que no tiene nada que ver con notificaciones.

Quién está en la zona de impacto

El requisito golpea a las apps UIKit, pero cómo te llega depende de tu stack.

El punto delicado para equipos cross-platform no es el framework, son los SDKs montados encima. Cualquier SDK de push o analytics que se instale envolviendo tu AppDelegate puede bloquear la migración a scene hasta que ese proveedor lance soporte para scene. Si una dependencia es dueña de tu entry point @main, estás esperando su release, no solo el tuyo. Vimos una migración estancada 2 semanas por exactamente esto, por una sola dependencia poco cooperativa, mientras todo lo que el equipo controlaba ya estaba listo. Revisa la compatibilidad de scene de tu SDK de notificaciones antes de asumir que la migración es cosa de un día. Si usas nuestro plugin de Flutter, la página de problemas conocidos de migración es lo primero que hay que leer.

El checklist de migración

La solución no ha cambiado desde que los scenes llegaron en 2019. Lo que cambió es que dejó de ser opcional.

• Agrega un manifiesto de scene. Pon un UIApplicationSceneManifest en tu Info.plist, o configura los scenes por código a través de los métodos de UIApplicationDelegate y UISceneDelegate.
• Crea un SceneDelegate. Si no tienes uno, agrégalo y asegúrate de que realmente compile dentro de tu target. Un SceneDelegate que existe en el proyecto pero nunca se agregó al build es una trampa común.
• Mueve la creación de la ventana. La propiedad de la ventana sale del AppDelegate. Reemplaza UIWindow(frame:) por UIWindow(windowScene:) y muestra tu vista raíz desde el scene.
• Mueve el manejo del ciclo de vida de UI. Las transiciones de foreground, background y active/inactive pasan a UISceneDelegate. Después de migrar, UIKit deja de llamar a los métodos de estado de UI en tu AppDelegate, así que lo que quede ahí muere en silencio.
• Deja el registro de push donde está. El registro del token y sus callbacks se quedan en AppDelegate. No los muevas persiguiendo simetría.
• Migra el manejo de URLs y deep links. Las URLs entrantes ahora llegan por métodos de scene. Si tus push abren pantallas específicas, esta es la parte que mantiene vivos tus deep links.
• Recompila y verifica la emisión del token. Compila con el SDK de iOS 27, lanza la app y confirma que recibe un token de APNs. Si no lo recibe, la guía de solución de errores de iOS es donde empezar. Verifica en un build real antes de publicar, no después.

Conserva el AppDelegate. Este es el punto que muchos equipos se pierden cuando leen “el AppDelegate va a desaparecer”. No desaparece. Su rol se reduce a eventos de proceso y de nivel de app, mientras el ciclo de vida de UI se muda al scene. El registro de push es una preocupación de nivel de app, y justo por eso se queda donde está.

Por qué apostarle solo al push es frágil

Da un paso atrás. Una sola clave de manifiesto, en un archivo que casi nadie del equipo abre, puede tirar todo tu canal de push en tu próxima versión. Es demasiada fragilidad apoyada en un solo método de entrega.

Y esto se suma a un techo que el push ya tenía: el opt-in. Incluso con una estrategia de prompt bien pensada, buena parte de tus usuarios en LATAM nunca otorga el permiso de push desde el arranque, así que el push llega a una fracción de tu base en un buen día. Rupturas de plataforma como esta solo agrandan la brecha entre a quién puedes llegar y a quién realmente le llegas.

Los equipos que capotean cambios como este son los que no dependen de un solo canal. Cuando el push es un método de entrega más junto a email, SMS y mensajes in-app, una regresión en el arranque de una sola plataforma te resta alcance en vez de borrarlo por completo. Te compras margen justo para el tipo de sorpresa que Apple acaba de soltar.

Revisa tu configuración de push para iOS 27 con Pushwoosh

El SDK de Pushwoosh ya soporta el ciclo de vida de scene de iOS 27, y su configuración multicanal significa que una ruptura en una sola plataforma nunca se lleva abajo toda tu estrategia de notificaciones. Si estás a mitad de la migración y algo no se registra, el FAQ del SDK de iOS cubre los tropiezos más comunes. Y si quieres un segundo par de ojos sobre si tu registro de push sobrevive el cambio, podemos revisar tu integración contigo.

Preguntas frecuentes