--- term: 'Notificações Push (APNs & FCM)' seoTitle: 'Notificações Push: APNs, FCM, Tokens de Dispositivo e Web Push' headline: 'O que são Notificações Push (APNs & FCM)?' slug: notificacoes-push category: backend-compute shortDefinition: '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.' relatedTerms: - websockets-real-time-sync - real-time-live-queries - background-jobs-task-schedulers - presence-online-status contrastsWith: - websockets-real-time-sync aboutTerms: - 'Token de Dispositivo' - 'APNs' - 'FCM' - 'Web Push (VAPID)' faq: - question: 'O que é notificação push?' answer: 'Uma mensagem iniciada no servidor, entregue ao dispositivo pelo serviço de push do sistema operacional e exibida mesmo quando o app não está rodando. Essa última propriedade é a que define o conceito — é o que separa o push das mensagens in-app, que precisam do app aberto, e dos sockets, que precisam de uma conexão viva.' - question: 'Como as notificações push funcionam de ponta a ponta?' answer: 'O app se registra no serviço de push da sua plataforma e recebe um token de dispositivo; o app entrega esse token ao seu backend; seu backend envia um payload mais o token ao APNs ou ao FCM; o serviço de push entrega pela conexão persistente que o SO mantém; o SO exibe a notificação ou acorda o app.' - question: 'O que é um token de dispositivo?' answer: 'Um identificador opaco de uma instalação do app em um dispositivo, emitido pelo serviço de push da plataforma — um endereço, não um segredo. Ele muda em reinstalações, restaurações ou limpezas de dados, e é por isso que os apps o ressincronizam com o backend a cada launch e os backends o excluem quando os envios reportam que ele morreu.' - question: 'Qual a diferença entre APNs e FCM?' answer: 'APNs (Apple Push Notification service) é a única estrada até dispositivos Apple. FCM é o serviço de push da plataforma Android — e dobra como camada cross-platform: com as credenciais APNs enviadas a ele, aceita uma request e reemite uma request compatível com APNs para os dispositivos Apple. Uma API, as duas plataformas.' - question: 'Por que meu servidor não pode fazer push direto para um dispositivo?' answer: 'Porque só o sistema operacional mantém a única conexão persistente, otimizada para bateria, com o seu serviço de push — um socket compartilhado por todos os apps do celular. Servidores arbitrários não conseguem manter conexões abertas através de rádios, NAT e estados de sono, então todo push passa pelos gateways da plataforma.' - question: 'Como funciona o web push?' answer: 'Por meio de service workers: a página se inscreve com a sua chave pública VAPID, o serviço de push do navegador retorna uma subscription — uma URL de endpoint mais chaves de criptografia — e seu servidor faz POST de payloads criptografados para esse endpoint conforme o Web Push Protocol. O evento push do service worker exibe a notificação, mesmo com o site fechado.' - question: 'A entrega do push é garantida?' answer: 'Não — uma resposta de sucesso do APNs ou do FCM significa aceito, não entregue. Dispositivos offline recebem filas coalescidas ou com prazo de validade, otimizadores de bateria atrasam a entrega e o usuário pode desativar as notificações por completo. Push é best-effort por design; qualquer coisa crítica precisa também de outro canal.' - question: 'O que são notificações push silenciosas?' answer: 'Pushes em segundo plano que acordam o app para buscar dados sem exibir alerta. São fortemente limitadas — pense num pequeno orçamento por hora, com envios acima dele descartados sem erro — então funcionam como dicas de refresh, nunca como transporte confiável de sincronização.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'Apple — Sending notification requests to APNs' url: 'https://developer.apple.com/documentation/usernotifications/sending-notification-requests-to-apns' - name: 'RFC 8030 — Generic Event Delivery Using HTTP Push' url: 'https://datatracker.ietf.org/doc/html/rfc8030' - name: 'RFC 8292 — VAPID for Web Push' url: 'https://datatracker.ietf.org/doc/html/rfc8292' - name: 'W3C Push API' url: 'https://www.w3.org/TR/push-api/' cta: title: 'Uma API de push para todo dispositivo' text: 'O serviço de push do Back4app guarda suas credenciais APNs e FCM uma única vez, acompanha cada instalação como um objeto Installation e envia por canal ou por consulta — do Cloud Code, do SDK ou do dashboard.' linkText: 'Comece grátis' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-08-21' translationKey: push-notifications-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 | Pergunta | Resposta | | --- | --- | | A cadeia | Seu backend → APNs/FCM → o único socket persistente do SO → o app | | O endereço | Token de dispositivo — por instalação, muda o tempo todo, precisa de sync e poda | | O contrato | Best-effort: aceito ≠ entregue, com throttling, desativável pelo usuário | | Os limites | Payloads de ~4 KB · flags de prioridade · pushes silenciosos num orçamento horário mínimo | | vs. sockets | Push alcança apps *fechados*; [WebSockets](/glossary/pt/websockets/) servem apps *abertos* | ## A cadeia de entrega, de ponta a ponta ```text 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:** ```javascript // 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 // 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. ``` **Swift:** ```swift // 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. ``` **Kotlin:** ```kotlin // 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. ``` ```mermaid flowchart LR accTitle: Entrega de notificação push através dos serviços de push das plataformas accDescr: O app se registra no serviço de push da sua plataforma e recebe um token de dispositivo, que sincroniza com o backend da aplicação. O backend envia payloads com tokens ao APNs ou ao FCM, que entregam pela única conexão persistente que cada sistema operacional mantém, e o SO exibe a notificação mesmo quando o app está fechado. A["App no dispositivo"] -->|"1 · registro"| PS["Serviço de push da plataforma
APNs / FCM"] PS -->|"2 · token de dispositivo"| A A -->|"3 · sync do token"| B["Seu backend
registro de tokens"] B -->|"4 · payload + token"| PS PS -->|"5 · uma conexão
persistente do SO"| OS["SO do dispositivo"] OS -->|"6 · exibe / acorda o app"| N["Notificação
(o app pode estar fechado)"] ``` ## 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 | | APNs | FCM | | --- | --- | --- | | Alcança | Dispositivos Apple — a única estrada | Android nativamente; dispositivos Apple via proxy para o APNs | | Autenticação | Chave de assinatura `.p8` (key ID + team ID) | Credenciais de servidor do console da plataforma | | Payload | ~4 KB · dicionário `aps` | ~4 KB · mensagens de notification + data | | Dispositivo offline | Coalesce — guarda só a *mais nova* por app | Fila com TTL, até ~4 semanas | | Prioridade | 10 (imediata) vs. 5 (amiga da bateria) | High vs. normal | | Extras | Collapse IDs, pushes em segundo plano | Topics, grupos de dispositivos, collapse keys | 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](https://developer.apple.com/documentation/usernotifications/sending-notification-requests-to-apns); 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](https://www.w3.org/TR/push-api/) usando o seu par de chaves **VAPID** ([RFC 8292](https://datatracker.ietf.org/doc/html/rfc8292) — 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](https://datatracker.ietf.org/doc/html/rfc8030). 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 | | Notificações push | [WebSockets](/glossary/pt/websockets/) / [live queries](/glossary/pt/live-queries-tempo-real/) | | --- | --- | --- | | Estado do app | **Fechado ou em segundo plano** | Aberto, conectado | | Direção | Uma via, servidor → dispositivo | Full duplex / push por subscription | | Latência e confiabilidade | Na casa de segundos, best-effort | Milissegundos, garantida pela conexão | | Payload | Resumo de ~4 KB + deep link | O que o seu protocolo carregar | | O híbrido | O padrão de produção: entregue pelo socket se conectado; caia para push depois de alguns segundos se não | | 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](/glossary/presence-online-status/). - **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 | Situação | Escolha | | --- | --- | | O usuário precisa saber mesmo com o app fechado | Push — seu trabalho por definição | | O app está aberto na tela | [Live queries / sockets](/glossary/pt/live-queries-tempo-real/) — mais rápidos, confiáveis | | O dado precisa chegar, garantido | Sua API + [sincronização em segundo plano](/glossary/background-jobs-task-schedulers/); push como o toque | | Público web | Web push via VAPID + service worker | | Sincronizações silenciosas frequentes | Não faça — o orçamento vai descartá-las; sincronize ao abrir | | Duas plataformas, um time | Uma API sobre os dois serviços — o modo proxy do FCM ou um BaaS | ## 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](/glossary/pt/cloud-code-funcoes-serverless/) — um `afterSave` em `Message` fazendo push para o destinatário é a metade de fallback do padrão híbrido — de [jobs](/glossary/background-jobs-task-schedulers/) 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.