Push Delivery, Tokens & Notification Preferences

Push Delivery and Notification Preferences

Push notifications are the most direct channel a product has to its users — and the easiest to abuse. Send too many, at the wrong time, or about the wrong things, and people disable notifications or uninstall the app. Send them carelessly, and they go to stale devices, arrive hours late, duplicate across a user's phone and tablet, or reveal private information on a lock screen.

Reliable, respectful push systems treat delivery as infrastructure and preferences as a product feature. On the delivery side: keep device tokens fresh, understand delivery states, and use priority, collapse, and expiration correctly. On the preference side: ask for permission in context, expose categories users can control (Android channels, iOS interruption levels), honor quiet hours and frequency caps on the server, and route messages to the right device or channel.

TL;DR

Register device tokens on every app start, handle token refresh, and prune tokens the provider reports as invalid or that go inactive.
"Sent" is not "seen": track accepted, delivered (where measurable), displayed, and opened.
Use priority, collapse keys, and expiration so urgent messages arrive promptly and stale ones are dropped.
Map categories to Android notification channels and iOS interruption levels; users control them.
Ask for permission in context, consider provisional delivery on iOS, and request Android 13+ runtime permission thoughtfully.
Enforce preferences, quiet hours, frequency caps, and consent on the server, and keep sensitive data out of payloads.

Quick Example

A server-side send through Firebase Cloud Messaging that checks preferences first and prunes dead tokens:

Creating notification channels on Android so users control each category in system settings:

Core Concepts

Token Lifecycle

Store tokens per installation, not per user, because one user has several devices and devices are shared.

Delivery States

Treat "accepted" as the end of your guarantee, measure the rest statistically, and use in-app inboxes for messages that must not be lost.

Priority, Collapse, and Expiration

High priority wakes the device immediately and is meant for time-sensitive, user-visible notifications; overuse can be deprioritized by the platform.
Collapse keys (collapse_key, apns-collapse-id) replace older undelivered notifications of the same kind — useful for "3 new comments" rather than three alerts.
Expiration / TTL drops notifications that are no longer useful if the device was offline.

Data-only and silent notifications are throttled and not guaranteed; see Mobile Background Work and Battery Limits.

Platform Controls

Design categories once and map them to channels and interruption levels consistently. Time-sensitive and critical levels require justification and, for critical alerts, Apple entitlement approval.

Permission Timing

Ask for notification permission when the value is clear — after a user follows a project or enables reminders — rather than at first launch. A brief in-app explanation before the system prompt increases acceptance, and denial is hard to reverse, so make it count.

Preferences and Routing on the Server

Preference center in the app and on the web: categories users can turn on or off, per channel (push, email, in-app).
Quiet hours in the user's time zone, with exceptions only for security and critical account messages.
Frequency caps and batching: combine many events into digests.
Cross-device deduplication: send to the most recently active device, or dismiss on others once one is read.
Fallbacks: email or in-app inbox when push is disabled or undelivered for important messages.
Consent: marketing pushes need explicit opt-in in many jurisdictions; keep records. See Consent Management.

Privacy and Security

Lock screens show notification content. Keep sensitive details (balances, health information, message contents) out of payloads, or show generic text and load details after the user unlocks and opens the app. Authenticate provider credentials securely (APNs token-based authentication keys, FCM service accounts) and rotate them.

Best Practices

Treat Tokens as Volatile

Refresh on every launch, store per installation, and prune invalid and stale tokens automatically.

Put Users in Control

Offer granular categories mapped to platform controls, and enforce preferences on the server, not only in the app.

Send Less, Better

Batch, digest, and cap frequency; measure opt-out and disable rates as health metrics.

Keep Payloads Private

Assume notification text is visible to anyone near the device.

Common Mistakes

Never Removing Dead Tokens

One Channel for Everything

Prompting on First Launch

FAQ

Why do push notification tokens change?

Tokens can change when apps are reinstalled, restored to new devices, or data is cleared, and providers may rotate them. Apps should send their current token to the server on every launch and handle refresh callbacks.

How do I know if a push notification was delivered?

Provider acceptance is reliable to measure; delivery and display are not guaranteed and are only partly observable through provider reports and client-side events. Measure opens through app analytics.

What are Android notification channels?

Categories an app defines with an importance level, which users can individually adjust or disable in system settings. Since Android 8, every notification belongs to a channel.

What is provisional authorization on iOS?

An option that lets an app deliver notifications quietly to Notification Center without first prompting the user, who can then choose to keep or turn them off.

Where should notification preferences be enforced?

On the server, before sending, so preferences apply consistently across devices and channels — complemented by platform controls on the device.