Push Notifications: Delivering Timely Signals Through Platform Services

An application server does not normally maintain its own permanent network connection to every sleeping phone.

Mobile platforms provide shared push infrastructure.

A push service accepts a small message from an application server and delivers a notification or wake-up signal to a registered app instance when conditions permit.

The platform is an intermediary. Delivery is useful but not a guaranteed real-time transaction channel.

A concrete example: a bank alert

After a card transaction:

1. The bank records the transaction.
2. Its notification service creates an alert.
3. It sends a message to the mobile platform's push service.
4. The platform routes it to the device.
5. The operating system displays it according to user settings.
6. Tapping opens the relevant transaction screen.

The bank targets a device token, not a raw phone network connection.

The authoritative transaction remains in the bank system even if the notification never arrives.

Device registration

The app asks the platform for a device-specific push token.

It sends that token to its backend along with authenticated account context.

The backend stores a relationship:

user 1042 -> app installation token xyz

A user may have several devices. One device may have several accounts over time.

Token registration needs ownership, platform, app version, locale, categories, and lifecycle management.

Do not treat a token as a permanent user ID.

The platform push service

Apple, Google, browser vendors, and other platforms operate push services.

They maintain efficient device connections and handle:

• Routing
• Device availability
• Battery-aware delivery
• Platform policy
• Notification display

Application servers authenticate to the push provider using keys or credentials.

Those provider credentials can send messages to many users and need strong secret management, scope, rotation, and audit.

Notification and data messages

A notification message contains display content such as:

• Title
• Body
• Badge
• Sound
• Category

A data message carries application data or a wake-up signal for code to process.

Platform behavior differs depending on whether the app is:

• Foreground
• Background
• Terminated

Background execution is restricted for battery and privacy.

Do not assume arbitrary code will run immediately after every data message.

Payloads should remain small

Push providers impose payload limits.

Use the message as a signal:

{
  "type": "order.updated",
  "orderId": "42"
}

The app fetches current authorized data from the API.

Avoid placing full private records, secrets, or long content in the payload.

Notifications may appear on lock screens and pass through provider infrastructure.

Minimize sensitive text and allow users to control previews.

Delivery is best effort

Push can be delayed or absent because:

• Device is offline
• Battery optimization delays work
• Permission is disabled
• Token expired
• Provider throttles
• App was uninstalled
• Platform incident occurs
• Notification is collapsed

Do not use push as the only record of:

• Payment
• Legal notice
• Medical instruction
• Security-critical state

The app should retrieve authoritative state when opened.

Use other channels and delivery evidence where obligations require them.

Collapse and replacement

For rapidly changing state, old messages may be obsolete.

A collapse key can let the platform retain only the latest:

delivery-status-order-42

This avoids showing:

• Driver assigned
• Driver nearby
• Driver arrived

long after delivery is complete.

Do not collapse distinct events that users need to see individually, such as separate security alerts.

Message semantics determine whether replacement is safe.

Priority and urgency

Platforms offer priority levels.

High priority may wake devices sooner but consumes battery and is restricted.

Use urgent delivery for genuinely time-sensitive user value:

• Incoming call
• Security warning
• Active delivery

Do not mark marketing messages high priority.

Abuse can lead to throttling, poor battery, user disablement, or store-policy action.

Priority is a scarce resource.

Notification permission and preference

Users control whether notifications appear.

Apps should request permission after explaining value, not automatically at first launch.

Provide categories:

• Security
• Transactions
• Messages
• Reminders
• Marketing

Some critical operational messages may have different policy treatment, but user choice and local law still matter.

Synchronize preferences between app and backend so disabled categories are not sent needlessly.

Deep linking

Tapping should open the relevant destination.

A deep link needs:

• Route
• Resource identifier
• Authentication
• Authorization
• Fallback if resource no longer exists

Do not trust payload text or route blindly.

If signed out, preserve a safe return destination after login.

If the account changed, ensure the resource belongs to the current account.

Deep-link handling is an input boundary.

Token lifecycle

Tokens can change after:

• Reinstallation
• Restore
• Platform rotation
• App data reset
• User account change

The app should register current tokens.

Providers may report invalid or unregistered tokens. Remove or deactivate them.

Stale tokens waste cost and can create privacy issues if a device changes ownership or account.

Do not log full tokens broadly.

Multiple devices and accounts

A user may want transaction alerts on two devices.

Another user may sign in on a shared tablet.

Model:

• User
• Installation
• Device token
• Active account association
• Preferences

On sign-out, remove or update the association without necessarily deleting a token needed for another account.

Avoid sending one user's private notification after an account switch.

Lifecycle tests should include shared and replaced devices.

Server-side sending

A notification pipeline often:

1. Receives domain event.
2. Evaluates user preferences.
3. Selects installations.
4. Localizes content.
5. Sends through provider API.
6. Processes provider response.
7. Records outcome.

Use queues to absorb bursts and isolate provider outages.

Idempotency prevents one domain event from producing repeated notifications unintentionally.

Retry temporary failures with backoff, but discard permanent invalid-token failures.

Security

Protect:

• Provider credentials
• Device tokens
• Deep-link parameters
• Notification content
• Registration endpoint

An attacker should not be able to register their token for another user's account.

Authenticate registration and bind it to the current installation.

Avoid allowing arbitrary notification text through a weak internal API.

Audit high-impact security and financial notifications.

Privacy and lock-screen content

Lock screens can expose messages to people nearby.

Use neutral text for sensitive domains:

You have a new secure message.

rather than medical or financial detail.

Allow preview controls.

The app can reveal full information after device and app authentication.

Notification analytics should not collect unnecessary behavioral detail or retain tokens indefinitely.

Localization and time zones

Notification content may be generated:

• On server
• On device using localization keys

Server localization supports dynamic text but needs user locale and pluralization.

Device localization can use installed translations but may not support arbitrary messages.

Schedule reminders in the user's intended time zone and handle daylight-saving changes.

Avoid sending nonurgent notifications during quiet hours.

Measurement

Providers may report:

• Accepted for delivery
• Invalid token
• Provider error

They often cannot prove the user saw or understood the notification.

App analytics can measure:

• Open
• Deep-link completion
• Disablement
• Conversion

Do not optimize only click rate.

Excessive or manipulative notifications may increase short-term opens and long-term uninstalls.

Measure user value and opt-out behavior.

Testing

Test:

• Foreground, background, terminated
• Permission granted and denied
• Offline device
• Token rotation
• Multiple accounts
• Shared device
• Expired resource
• Deep link after login
• Localization
• Collapsed messages
• Provider retry

Use sandbox and real-device environments.

Push behavior differs across platform versions, manufacturer settings, and battery modes.

Knowledge check

1. Why does an app server use a platform push service?
2. Why should a payload usually carry an identifier rather than a full private record?
3. What does a collapse key accomplish?
4. Why is a device token not a permanent user identity?
5. Why does provider acceptance not prove the user saw a notification?

The one idea to remember

Push is a best-effort signal routed through platform infrastructure. Treat tokens, permission, payload privacy, delivery delay, deep links, and user attention as explicit parts of the product rather than assume every message arrives instantly.