O que são Notificações Push (APNs & FCM)?

Uma notificação push é uma mensagem iniciada no servidor que os serviços de push da plataforma entregam ao dispositivo mesmo com o app fechado. Times de produto conhecem o push como canal de engajamento; este verbete cobre a maquinaria de entrega — porque a maquinaria explica cada esquisitice de que os times de produto reclamam. O fato central: seu servidor nunca fala com o celular. Cada sistema operacional mobile mantém exatamente uma conexão persistente e otimizada para bateria com o seu gateway de push — APNs (Apple Push Notification service) no iOS, FCM no Android — e toda notificação de todo app viaja por esse cano compartilhado.

Principais pontos

A cadeia de entrega, de ponta a ponta

1  O app pede ao SO o registro para push
2  O serviço de push da plataforma emite um TOKEN DE DISPOSITIVO (o endereço)
3  O app envia o token ao SEU backend, que o armazena
4  Algo acontece → o backend faz POST de { token, payload ≤4 KB } ao APNs / FCM
5  O serviço de push localiza a conexão persistente do dispositivo → entrega
6  O SO exibe a notificação — ou acorda o app por instantes num push silencioso

O segundo papel do FCM: com as credenciais APNs enviadas a ele, aceita uma
request e reemite uma request compatível com APNs para dispositivos Apple —
uma única superfície de API para as duas plataformas. Um BaaS abstrai até isso.

As duas metades em código — o cliente registrando seu endereço, o backend enviando a um canal:

// JavaScript — Cloud Code (cloud/main.js)
// One send call reaches both platform push services
await Parse.Push.send({
  channels: ['scores'], // or `where:` with an Installation query
  data: {
    alert: 'Kickoff! Follow the match live.',
    badge: 'Increment',
    uri: 'app://match/8fk2',
  },
}, { useMasterKey: true });
// Back4app routes to APNs for Apple devices and FCM for Android — one API

// Flutter / Dart — Back4app Flutter SDK
// Register this install for push: token + channels live in an Installation
final installation = await ParseInstallation.currentInstallation();
installation
  ..set('channels', ['scores']) // subscribe to a topic-like channel
  ..set('user', currentUser);   // enables targeting by user later
await installation.save();
// deviceToken and deviceType are captured automatically — your backend
// now addresses this device without touching APNs or FCM directly.

// iOS / Swift — Back4app Swift SDK
// Register this install for push: token + channels live in an Installation
var installation = ParseInstallation.current
installation?.channels = ["scores"] // topic-like channel
installation?.user = currentUser    // enables targeting by user later
try await installation?.save()
// deviceToken and deviceType are captured automatically — your backend
// now addresses this device without touching APNs directly.

// Android / Kotlin — Back4app Android SDK
// Register this install for push: token + channels live in an Installation
val installation = ParseInstallation.getCurrentInstallation()
installation.put("channels", listOf("scores")) // topic-like channel
installation.put("user", ParseUser.getCurrentUser()) // target by user later
installation.saveInBackground()
// deviceToken and deviceType are captured automatically — your backend
// now addresses this device without touching the push services directly.

Tokens de dispositivo: o endereço que não para de mudar

O ciclo de vida do token é o trabalho de verdade do backend, e a parte que as páginas explicativas pulam. Registrar: o SO emite um token por instalação do app. Armazenar: o app o sincroniza com seu backend a cada launch — tokens mudam em reinstalação, restauração e limpeza de dados, silenciosamente. Endereçar: os envios apontam para tokens, individualmente ou via registro. Invalidar: envios a tokens mortos voltam com erros específicos — 410 Gone do APNs, erros de token não registrado do FCM — e o FCM aposenta tokens sem uso por cerca de nove meses. Podar: exclua ao ver esses erros, imediatamente. Backends que pulam o último passo acumulam tabelas de tokens apodrecendo, que desperdiçam envios, distorcem métricas de entrega e atrasam campanhas — o problema do token velho é chato, cumulativo e o bug de push mais comum no mundo real.

APNs vs. FCM

A consequência prática da primeira linha: todo backend cross-platform ou integra os dois serviços, ou usa o FCM como superfície única (enviando as credenciais APNs a ele), ou entrega o problema inteiro a uma plataforma que guarda os dois conjuntos de credenciais — que é onde a seção de BaaS aterrissa.

O que o push não promete

O contrato honesto, reunido num lugar só. Um 200 do serviço de push significa aceito para entrega, não entregue. Dispositivos offline não acumulam uma fila fiel: o APNs guarda apenas a notificação mais recente por app; a fila do FCM expira num TTL. Otimizadores de bateria no Android adiam a entrega de formas que você não controla; o usuário pode silenciar um canal ou o app inteiro no nível do SO, invisivelmente para o seu backend. Pushes silenciosos — despertares em segundo plano sem alerta visível — rodam num orçamento horário mínimo e são descartados sem erro além dele, conforme a orientação da própria Apple; são dicas de refresh, não um protocolo de sincronização. A regra de design que decorre disso: push é o toque no ombro — os dados em si viajam pela sua API quando o app abre, e qualquer coisa que precisa chegar ganha um segundo canal.

Web push, em resumo

Os navegadores padronizaram sua própria cadeia: a página se inscreve via Push API usando o seu par de chaves VAPID (RFC 8292 — o servidor se identifica com um token assinado, sem registro junto a fornecedor), o serviço de push do navegador retorna uma subscription (URL de endpoint + chaves de criptografia) e seu servidor faz POST de payloads criptografados para esse endpoint conforme o Web Push Protocol. Um service worker recebe o evento push e exibe a notificação — site fechado, navegador talvez fechado no desktop. Cada fabricante de navegador roda seu próprio serviço de push; a URL do endpoint diz ao seu servidor onde fazer o POST. A ressalva honesta: no iOS, o web push só funciona para web apps instalados na Tela de Início.

Push vs. WebSockets vs. live queries

São complementos com uma fronteira: o socket serve o usuário olhando para a tela; o push alcança o usuário que largou o celular. Apps de chat demonstram o híbrido diariamente — mensagens fluem pela conexão enquanto o app está aberto, e a mesma mensagem vira push no momento em que ele deixa de estar.

Casos de uso comuns

• Mensagens e menções — o push canônico: alguém precisa de você, o app está fechado.
• Alertas transacionais — pedido enviado, carro chegando, pagamento aprovado: resumos de uma linha com deep link para dentro do app.
• Gatilhos sensíveis ao tempo — mudanças de placar, alertas de preço, momentos “X está ao vivo” vizinhos de presença.
• Reengajamento — usado com parcimônia, com opt-out por canal, ou os usuários desativam tudo.
• Badges e dicas de estado — o orçamento silencioso gasto em cutucar o app para atualizar antes de o usuário abrir.

Você deveria usar push? Matriz de decisão

Limitações e trade-offs

• Entrega é probabilidade, não promessa. Projete fluxos que sobrevivam a um push perdido; reconcilie ao abrir o app.
• Permissões são capital de um tiro só. O prompt do SO (explícito no iOS e na web, em runtime no Android moderno) converte melhor pedido em contexto — e um prompt negado é quase irreversível.
• O registro de tokens é um dataset vivo. Sincronize no launch, pode ao errar, ou veja a entregabilidade decair em silêncio.
• Payloads são meio públicos. Notificações aparecem em telas de bloqueio e atravessam infraestrutura de terceiros — resumos e IDs, nunca segredos.
• Dois sistemas de credenciais, uma feature. Chaves .p8, credenciais de console, expiração e rotação — a dor de configuração é real, uma vez por plataforma, e é exatamente o que camadas gerenciadas absorvem.

Push no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. O serviço de push do Back4app transforma a cadeia inteira em dados: cada instalação se registra como um objeto Installation — token de dispositivo, plataforma, canais e um ponteiro de usuário capturados automaticamente, como mostram as abas de cliente — e uma única chamada de envio endereça canais (estilo tópicos) ou qualquer consulta de Installations (“todo mundo em scores no Android que não abriu o app esta semana”), com a plataforma guardando suas credenciais APNs e FCM e roteando por dispositivo. Os envios disparam do Cloud Code — um afterSave em Message fazendo push para o destinatário é a metade de fallback do padrão híbrido — de jobs agendados, ou do console do dashboard para campanhas pontuais. Higiene de tokens, credenciais duplas e esquisitices de payload por plataforma viram comportamento da plataforma; seu código decide quem e o quê, não como.