iOS 27 quebra push notifications sem UISceneDelegate: veja a solução

Se você compila seu app contra o SDK do iOS 27 sem adotar o UIScene lifecycle, o app simplesmente não abre. E um app que não abre nunca se registra para push, então suas notificações somem sem nenhum crash report apontando o push como causa. O sintoma parece um problema de entrega. Na real, é um problema de inicialização.

Essa pegadinha derruba muito time de guarda justamente porque push e inicialização do app parecem assuntos sem nenhuma relação — no código e na cabeça de quem trabalha neles. O iOS 27 amarrou os dois. Este guia explica o que quebra, a cadeia exata que silencia suas notificações, quem está na linha de frente e o checklist de migração para resolver. A Pushwoosh é uma plataforma de engajamento de clientes, e nosso SDK para iOS já cobre essa transição, mas a correção abaixo vale independente de você usar a gente ou não.

O que realmente quebra

A Apple anunciou na WWDC25 que a versão seguinte ao iOS 26 exigiria o UIScene lifecycle para qualquer app UIKit compilado com o SDK mais recente. O iOS 27 é essa versão. A exigência já está valendo.

O gatilho importa, e a maioria das threads em pânico erra justamente nesse ponto: a exigência entra em vigor quando você compila contra o SDK do iOS 27 no Xcode 27, não simplesmente quando um usuário abre seu app já existente em um iPhone com iOS 27. Seu build publicado hoje continua funcionando normalmente nos aparelhos atualizados. A quebra chega no seu próximo release, compilado com o SDK novo. Essa diferença te dá um tempo, mas só até o próximo envio.

O que não muda — e é aí que os textos alarmistas exageram — é o fluxo do APNs em si, que segue intacto. Você continua pedindo autorização, continua chamando registerForRemoteNotifications(), e continua recebendo o device token em didRegisterForRemoteNotificationsWithDeviceToken. Esse callback continua no AppDelegate, e hoje não existe um equivalente baseado em scene no iOS 27 para mover isso. A mecânica de push está tranquila. O que a Apple mudou foi a inicialização.

A cadeia que silencia seu push

Quando um app sem manifesto de scene é compilado contra o SDK do iOS 27, a falha acontece nesta ordem:

1. O UIKit exige adoção de scene na inicialização e não encontra nenhum UIApplicationSceneManifest no seu Info.plist.
2. O app é encerrado antes de qualquer método do AppDelegate rodar.
3. Como application(_:didFinishLaunchingWithOptions:) nunca executa, registerForRemoteNotifications() também nunca dispara.
4. Sem registro, didRegisterForRemoteNotificationsWithDeviceToken nunca é chamado, então o app nunca recebe um token do APNs.
5. Sem token, sem entrega. E como o app crashou na inicialização, seus logs apontam para o lançamento, não para o pipeline de notificações.

O motivo de isso consumir tanto tempo de debug é que o sintoma e a causa ficam bem distantes um do outro. Você vê entregas faltando e começa a auditar seu provedor de push, seus payloads, seus certificados. A falha real está três camadas acima, num arquivo de manifesto que não tem nada a ver com notificações.

Quem está na linha de frente

A exigência atinge apps UIKit, mas o quanto ela te atinge depende do seu stack.

O ponto sensível para times cross-platform não é o framework, são os SDKs empilhados em cima dele. Qualquer SDK de push ou analytics que se instala envolvendo seu AppDelegate pode travar a migração para scene até o fornecedor lançar suporte a scene. Se uma dependência é dona do seu entry point @main, você está esperando o release dela, não só o seu. Já vimos uma migração travada por 2 semanas exatamente por isso — uma única dependência não colaborativa, enquanto tudo que o time controlava já estava pronto. Confira a compatibilidade com scene do seu SDK de notificações antes de assumir que a migração é coisa de um dia. Se você usa nosso plugin de Flutter, a página de problemas conhecidos de migração é o primeiro lugar pra olhar.

O checklist de migração

A correção não mudou desde que os scenes chegaram em 2019. O que mudou é que deixou de ser opcional.

• Adicione um manifesto de scene. Coloque um UIApplicationSceneManifest no seu Info.plist, ou configure scenes via código com os métodos de UIApplicationDelegate e UISceneDelegate.
• Crie um SceneDelegate. Se você não tem um, adicione e garanta que ele realmente compila dentro do seu target. Um SceneDelegate que existe no projeto mas nunca foi adicionado ao build é uma armadilha comum.
• Mova a criação da janela. A posse da janela sai do AppDelegate. Troque UIWindow(frame:) por UIWindow(windowScene:) e hospede sua view raiz a partir do scene.
• Mova o tratamento do ciclo de vida de UI. As transições de foreground, background e active/inactive vão para o UISceneDelegate. Depois da migração, o UIKit para de chamar os métodos de estado de UI no seu AppDelegate, então o que ficar lá para de funcionar sem avisar.
• Deixe o registro de push onde está. O registro do token e seus callbacks continuam no AppDelegate. Não mova por conta de simetria.
• Migre o tratamento de URL e deep link. URLs recebidas agora chegam pelos métodos de scene. Se seu push abre telas específicas, essa é a parte que mantém seus deep links funcionando.
• Recompile e verifique a emissão do token. Compile com o SDK do iOS 27, abra o app e confirme que ele recebe um token do APNs. Se não receber, o guia de troubleshooting de erros do iOS é o ponto de partida. Verifique em um build real antes do lançamento, não depois.

Mantenha o AppDelegate. Esse é o ponto que os times mais erram ao ler “o AppDelegate vai sumir”. Ele não vai sumir. O papel dele encolhe para eventos de processo e de nível de app, enquanto o ciclo de vida de UI migra para o scene. Registro de push é uma questão de nível de app, e é exatamente por isso que ele fica onde está.

Por que apostar só no push é frágil

Dá um passo atrás. Uma única chave de manifesto, num arquivo que quase ninguém do time abre, pode derrubar todo seu canal de push no próximo release. É muita fragilidade concentrada num único método de entrega.

E isso soma a um teto que o push já tem por natureza: o opt-in. Mesmo com uma estratégia de solicitação de permissão bem pensada, boa parte dos seus usuários nunca concede a permissão de push desde o início, então o push alcança só uma fração da sua base num dia bom. Quebras de plataforma como essa só aumentam a distância entre quem você poderia alcançar e quem você realmente alcança.

Os times que atravessam mudanças assim tranquilos são os que não dependem de um canal só. Quando o push é só mais um método de entrega ao lado de e-mail, SMS e in-app, uma regressão na inicialização de uma única plataforma reduz seu alcance em vez de zerar ele. Isso te dá justamente a margem que você precisa pra uma surpresa como essa que a Apple acabou de soltar.

Peça pra Pushwoosh revisar sua configuração de push do iOS 27

O SDK da Pushwoosh já suporta o scene lifecycle do iOS 27, e a configuração multicanal significa que uma quebra numa única plataforma nunca derruba toda a sua estratégia de notificações junto. Se sua migração está em andamento e algo não está registrando, o FAQ do SDK iOS cobre os problemas mais comuns. E se você quiser um segundo olhar pra confirmar se seu registro de push sobrevive à mudança, a gente pode revisar sua integração junto com você.

Perguntas frequentes