Push notifications parecem mágica: o servidor "manda" uma mensagem e ela aparece no celular mesmo com o app fechado. Por baixo há um fluxo bem definido envolvendo permissão, um token de dispositivo e os serviços da Apple (APNs) e do Google (FCM). Entender esse caminho de ponta a ponta — e por que a entrega nunca é 100% garantida — é esperado de um sênior.
O fluxo de ponta a ponta
1. App pede permissao ao usuario
2. SO/serviço devolve um TOKEN unico do dispositivo
3. App envia o token ao SEU backend, que o guarda
4. Backend manda a mensagem + token para APNs (Apple) ou FCM (Google)
5. APNs/FCM entrega ao dispositivo certo
6. SO exibe a notificacao (ou acorda o app)A analogia: o token é como o endereço de entrega do dispositivo. Seu servidor não entrega o pacote em mãos — ele dá o pacote e o endereço para os Correios (APNs/FCM), e estes fazem a entrega física.
Permissão: o usuário decide
No iOS (e a partir do Android 13) o app precisa pedir permissão para notificar. Se o usuário recusa, não há push — ponto. Por isso pede-se a permissão no momento certo, explicando o valor, e não logo na primeira tela. É comum em entrevista pedir para descrever esse passo e suas implicações de UX e de taxa de entrega.
O token do dispositivo
Após a permissão, o serviço do SO gera um token que identifica aquele app naquele aparelho. Pontos cruciais:
- O token pode mudar (reinstalação, troca de aparelho, atualização) — seu backend precisa atualizá-lo.
- Um usuário pode ter vários tokens (vários dispositivos).
- Token inválido/expirado deve ser removido do banco, ou você desperdiça envios.
APNs e FCM: os carteiros
Seu backend nunca fala direto com o dispositivo. Ele autentica-se no APNs (Apple Push Notification service) para iOS ou no FCM (Firebase Cloud Messaging) para Android, envia a mensagem com o token de destino, e o serviço cuida da entrega — inclusive de acordar o app se necessário.
[ Seu backend ]
| (mensagem + token + auth)
v
[ APNs / FCM ] <- fila best-effort
|
v
[ Dispositivo ] --> SO exibe notificacaoNotificação vs data message
Há dois tipos de payload, e a diferença cai em entrevista:
| Tipo | O que faz | App fechado? |
|---|---|---|
| Notification | SO exibe o alerta automaticamente (título/corpo) | Aparece sem o app rodar |
| Data message | Entrega dados ao app para ele decidir o que fazer | Depende do SO acordar o app; pode ser adiado |
Um payload pode combinar os dois. A escolha define se o SO mostra sozinho ou se seu código processa (ex.: atualizar um cache em silêncio).
Por que a entrega não é garantida
Push é best-effort, não garantido. A mensagem pode não chegar (ou atrasar) porque:
- O dispositivo está offline; APNs/FCM guardam por um tempo e podem descartar.
- O SO está economizando bateria (Doze/App Standby no Android) e adia o trabalho.
- O sistema agrupa ou limita data messages de apps "inativos".
- O usuário desativou notificações.
Por isso push nunca deve ser o único canal de uma informação crítica: ele avisa, mas a fonte da verdade está no servidor, e o app deve revalidar ao abrir.
Trate push como um lembrete, não como um canal confiável de dados. Se a informação for indispensável, o app precisa conseguir obtê-la sozinho ao abrir — o push só apressa a descoberta.
Conclusão
O fluxo permissão → token → backend → APNs/FCM → dispositivo, a diferença entre notification e data message, e a natureza best-effort da entrega são o núcleo do que se espera saber sobre push. Quem entende que o serviço da plataforma é o carteiro — e que o app não pode depender 100% dele — projeta notificações que funcionam sem criar bugs de dados.
Push notifications look like magic: the server "sends" a message and it shows up on the phone even with the app closed. Underneath is a well-defined flow involving permission, a device token and the Apple (APNs) and Google (FCM) services. Understanding this path end to end — and why delivery is never 100% guaranteed — is expected of a senior.
The end-to-end flow
1. App asks the user for permission
2. The OS/service returns a unique device TOKEN
3. App sends the token to YOUR backend, which stores it
4. Backend sends the message + token to APNs (Apple) or FCM (Google)
5. APNs/FCM delivers to the right device
6. The OS displays the notification (or wakes the app)The analogy: the token is the device's delivery address. Your server doesn't hand-deliver the package — it gives the package and the address to the postal service (APNs/FCM), which does the physical delivery.
Permission: the user decides
On iOS (and from Android 13 on) the app must ask permission to notify. If the user declines, there's no push — period. That's why you ask for permission at the right moment, explaining the value, and not on the very first screen. Interviewers often ask you to describe this step and its implications for UX and delivery rate.
The device token
After permission, the OS service generates a token that identifies that app on that device. Crucial points:
- The token can change (reinstall, new device, update) — your backend needs to keep it updated.
- A user can have several tokens (multiple devices).
- Invalid/expired tokens should be removed from the database, or you waste sends.
APNs and FCM: the mail carriers
Your backend never talks directly to the device. It authenticates with APNs (Apple Push Notification service) for iOS or FCM (Firebase Cloud Messaging) for Android, sends the message with the destination token, and the service handles delivery — including waking the app if needed.
[ Your backend ]
| (message + token + auth)
v
[ APNs / FCM ] <- best-effort queue
|
v
[ Device ] --> OS displays notificationNotification vs data message
There are two kinds of payload, and the difference comes up in interviews:
| Type | What it does | App closed? |
|---|---|---|
| Notification | The OS displays the alert automatically (title/body) | Shows up without the app running |
| Data message | Delivers data to the app so it decides what to do | Depends on the OS waking the app; may be deferred |
A payload can combine both. The choice defines whether the OS shows it on its own or your code processes it (e.g., silently updating a cache).
Why delivery isn't guaranteed
Push is best-effort, not guaranteed. The message may not arrive (or may be delayed) because:
- The device is offline; APNs/FCM hold it for a while and may discard it.
- The OS is saving battery (Doze/App Standby on Android) and defers the work.
- The system batches or throttles data messages for "inactive" apps.
- The user turned off notifications.
That's why push should never be the only channel for critical information: it alerts, but the source of truth is on the server, and the app should revalidate when it opens.
Treat push as a reminder, not a reliable data channel. If the information is indispensable, the app must be able to get it on its own when it opens — push only speeds up discovery.
Conclusion
The flow permission → token → backend → APNs/FCM → device, the difference between notification and data message, and the best-effort nature of delivery are the core of what's expected to know about push. Whoever understands that the platform service is the mail carrier — and that the app can't depend on it 100% — designs notifications that work without creating data bugs.