Push is not a message queue. APNs and FCM are best-effort systems that will drop, delay, collapse or refuse your notifications for reasons they mostly do not report back. Teams discover this when a time-sensitive alert does not arrive and the logs say it was sent successfully. Treating push as a delivery guarantee is the root cause of nearly every notification incident.
01Why notifications go missing
The device may be offline, in which case the platform stores a limited number of notifications and discards older ones. It may be in a battery-saving state that defers delivery indefinitely. The user may have revoked permission without your backend knowing. The token may have been invalidated by a reinstall.
Priority matters more than most teams realise. Low-priority notifications on both platforms can be delayed for a long time or coalesced away entirely when the device is idle. Sending everything at high priority is not the fix either - platforms throttle senders who abuse it.
Silent or data-only pushes are the least reliable category by design. They are a hint that your app might want to wake up, not an instruction, and treating them as a sync trigger without a fallback produces exactly the intermittent staleness users report as 'the app does not update'.
02Build for the case where it does not arrive
The architectural rule is that push should accelerate a state change, never be the only way one propagates.
That means the app must be able to reach a correct state by fetching on foreground, and the notification is an optimisation on top of that. If your app only learns about new data via push, every dropped notification is a correctness bug.
- Always reconcile on app foreground. Push is a hint; the fetch is the truth.
- Handle token rotation properly - store the token per install, refresh on every launch, and delete on logout.
- Process the invalid-token feedback both platforms return, or your delivery rate degrades quietly for months.
- Use collapse keys deliberately so a burst of updates does not produce a burst of notifications.
- Never put anything sensitive in the payload; notification content is visible on a locked screen and passes through platform infrastructure.
03Measuring delivery
Send-side success means the platform accepted the request, not that the device received it. Those numbers diverge substantially and the gap is invisible unless you close the loop.
Instrument receipt on the device and report it back. The difference between sends and receipts is your real delivery rate, and it is usually well below what teams assume. Segment it by platform and OS version - regressions are often confined to one.
Permission state is the other half. Track how many installs have push enabled, because that number decays and a falling delivery rate is often a permissions story rather than an infrastructure one.
04What users actually tolerate
The technical ceiling is not the constraint; attention is. Permission revocation and uninstalls correlate strongly with notification volume, and once revoked you rarely get it back.
Treat the permission prompt as a scarce resource. Asking on first launch, before the user understands what they would receive, produces the lowest acceptance rates. Ask at the moment the value is obvious, and be specific about what you will send.
Topics
Aarav Patel
Principal Engineer · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.
Talk to an engineer