Push &Local Notifications — An Expert Technical Study Across Android, iOS, macOS, Web, and Windows Part2

Silent Push & Real-Time Notification Requirements

Why silent push is not real-time — by design

A silent push ( content-available: 1 on iOS, data-only messages on Android) asks the OS to spend battery running your code with no user-visible payoff . Operating systems therefore treat it as a discretionary favor, not a delivery contract. Delay and drop causes stack multiplicatively:

• Priority rules: iOS background pushes must use apns-priority: 5 , which explicitly permits coalescing and deferral; APNs may also batch several into one wake-up, delivering only the newest per collapse ID.
• Budgets: iOS grants each app a limited background-push budget influenced by user engagement, battery, and thermal state — in practice a few per hour, sometimes fewer.
• Device state: Low Power Mode slashes budgets to near zero; Background App Refresh off disables content-available processing entirely; user force-quit blocks silent pushes completely (iOS) and data delivery (Android force-stop); Doze/Standby buckets defer normal-priority FCM to maintenance windows; Focus doesn't block the data path but correlates with the states that do.
• Network: the device's push socket rides radio wake-up cycles; on poor networks the OS batches to save power.

Correct architectures per use case

Server-side retry, idempotency, and fallback

• Idempotency: every logical event carries a stable eventId ; client dedupes on display and on DB insert. Retries then become safe by construction.
• Retry policy: retry provider-level failures (5xx/connection) with exponential backoff + jitter; do not retry semantic rejections (400/410/413/403-auth) except after fixing the cause. Cap total attempts by message class (an OTP older than 5 minutes should die, a billing notice can retry for a day).
• Escalation ladder for must-see events: silent hint → (no client ack within N seconds) → user-visible push → (still no ack) → SMS/email fallback for the OTP/security class. The client "ack" is a lightweight API call your app makes when it processes the event — this is how you detect the silent tier failing per user and adapt.
• Race-proofing: pushes and API responses race. The client must treat push payloads as invalidation signals , not as source of truth: on receipt, fetch canonical state (or apply the payload only if its version ≥ local version).

WebSocket vs push — the trade-off table

Hybrid architecture is the industry answer: WebSocket while the app is foreground/active (presence, typing, sub-second updates); push for everything else; reconciliation fetch stitching the two so neither channel needs to be lossless. The server publishes each event once to a fan-out layer that routes per-device based on connection state ("socket if connected, else push"), with idempotent event IDs making duplicate delivery across both channels harmless.

Browser / Web Push Deep Dive

The three-standard stack

Web Push is service-worker-centric: a worker registered by your page outlives the page and is woken by the browser for push events. The Push API handles subscription and delivery; the Notifications API handles display ( registration.showNotification() ); the wire protocol is standardized (RFC 8030) with mandatory payload encryption (RFC 8291, aes128gcm ) and server identification via VAPID (RFC 8292).

const reg = await navigator.serviceWorker.register("/sw.js");
const sub = await reg.pushManager.subscribe({
  userVisibleOnly: true,                       // required by Chrome
  applicationServerKey: urlBase64ToUint8Array(VAPID_PUBLIC_KEY)
});
await api.saveSubscription(sub.toJSON());       // { endpoint, keys: { p256dh, auth } }

self.addEventListener("push", (event) => {
  const data = event.data?.json() ?? {};
  event.waitUntil(
    self.registration.showNotification(data.title ?? "Update", {
      body: data.body, icon: "/icons/192.png", badge: "/icons/badge-72.png",
      tag: data.dedupKey,                       // same tag replaces, doesn't stack
      renotify: false,
      data: { url: data.deepLink }
    })
  );
});
self.addEventListener("notificationclick", (event) => {
  event.notification.close();
  event.waitUntil(clients.openWindow(event.notification.data.url));
});

VAPID and the subscription lifecycle

• VAPID : your server holds one ES256 keypair; each push request carries a short-lived self-signed JWT ( aud = push-service origin, sub = mailto/URL contact, exp ≤ 24 h) plus the public key. The public key also binds the subscription — rotating VAPID keys invalidates every existing subscription ; treat the private key like a production credential.
• Lifecycle: subscriptions die when the user clears site data, revokes permission, the push service rotates, or the browser expires them (Chrome enforces expiration; Safari subscriptions are comparatively long-lived). Handle: (a) pushsubscriptionchange in the worker — resubscribe and re-upload; (b) HTTP 404/410 from the push service — delete server-side; (c) on every page load, compare pushManager.getSubscription() with what the server has.

Permission UX — the highest-stakes prompt on the web

• Browsers punish prompt abuse: Chrome and Firefox show quieter UI (crossed bell) for sites with poor accept rates or when prompting without engagement; Safari and Firefox require a user gesture outright. A denial is sticky per origin and users almost never dig into site settings to reverse it.
• Best practice mirrors mobile: contextual pre-prompt ("Get notified when your report is ready") → real prompt only on explicit click → graceful degradation (in-app inbox, email) on denial.

Sending: encryption and control headers

• Payloads are encrypted to the subscription's p256dh / auth keys — the push service cannot read them. Use a maintained library ( web-push for Node.js — a natural fit alongside your existing docx-generation stack — or pywebpush ); hand-rolling RFC 8291 is a security bug factory.
• Protocol headers: TTL (seconds the service should hold an undelivered message — 0 = now-or-never), Urgency ( very-low … high , lets the browser delay low-urgency pushes on battery), Topic (collapse key: newest replaces pending with the same topic).

Browser differences that bite

PWA considerations and edge cases

• Installed PWAs get app-like presence (icon/name in OS notification settings, badging API); on iOS, installation is a precondition for push — design the "Add to Home Screen" education flow as part of your opt-in funnel.
• Service worker updates: a waiting worker doesn't handle pushes until activated; a broken deployed worker silently eats pushes — version your worker and monitor a heartbeat push in synthetic tests.
• Edge cases:  multiple browser profiles = multiple subscriptions for one human (frequency-cap per user, not per subscription); private windows don't allow push; enterprise policies can disable notifications wholesale; the OS-level Focus/Do-Not-Disturb still suppresses whatever the browser shows

Backend Architecture

Service design: one pipeline, many providers

A production notification service is a pipeline with strict stage boundaries , not a helper function that calls FCM. The canonical shape:

1. Ingestion API — internal services publish notification intents ("order 4417 shipped to user u_91") with an idempotency key; never raw device sends.
2. Decision layer — preference center, quiet hours, frequency caps, dedup, channel selection (push vs email vs in-app), template + localization resolution.
3. Fan-out — resolve user → active devices/subscriptions; emit one delivery job per endpoint onto a queue.
4. Provider workers — per-provider sender pools (APNs HTTP/2 connection pools, FCM batches, WNS, Web Push) implementing that provider's auth, rate, and error semantics.
5. Feedback loop — provider responses, client display/open acks, and token-invalidation events flow back into the device registry and analytics.

Token/device registry schema

-- One row per app installation per user session context
CREATE TABLE device_endpoints (
  id               UUID PRIMARY KEY,
  user_id          UUID NOT NULL,            -- current owner (nullable pre-login)
  installation_id  TEXT NOT NULL,            -- client-generated stable install UUID
  platform         TEXT NOT NULL,            -- android | ios | ios_voip | macos | web | windows
  provider         TEXT NOT NULL,            -- fcm | apns | apns_voip | webpush | wns
  token            TEXT NOT NULL,            -- token / endpoint URL / channel URI
  webpush_keys     JSONB,                    -- p256dh + auth for web only
  apns_environment TEXT,                     -- sandbox | production
  app_version      TEXT,
  locale           TEXT, timezone TEXT,
  status           TEXT NOT NULL DEFAULT 'active',  -- active | invalid | logged_out
  last_seen_at     TIMESTAMPTZ,
  updated_at       TIMESTAMPTZ NOT NULL,
  UNIQUE (installation_id, platform)         -- upsert target: token rotates, install persists
);
CREATE INDEX ON device_endpoints (user_id) WHERE status = 'active';
CREATE UNIQUE INDEX ON device_endpoints (provider, token);

• Upsert by installation, not token: when onNewToken /resubscribe fires, the row updates in place; a token seen on a different installation means a restore-clone — invalidate the older row (Section 13).
• User–device mapping: login binds user_id ; logout must flip status (do not delete — you need the token to send nothing to it, and audit history). Multiple users on one device over time is normal; one user on many devices simultaneously is the default assumption.

Queueing, retries, DLQs

• Queue per priority class (realtime / transactional / bulk) so a 5M-user campaign cannot delay OTPs. Workers drain realtime first; bulk is rate-shaped.
• Retry taxonomy: transient (provider 5xx, 429, timeouts) → exponential backoff + jitter, bounded by the message's business TTL; permanent (400 malformed, 403 auth, 410 dead token) → no retry, fix or clean up. Respect per-provider signals: APNs 429 is per-token; FCM 429 wants global backoff on the indicated scope; WNS returns explicit retry headers.
• Dead-letter queue for jobs exhausting retries, with the full provider response attached. DLQ volume by error class is one of your best health dashboards; a spike in ExpiredProviderToken is an auth incident, a spike in 410s after a release is a client registration bug.

Dedup, collapse, priority, rate limiting

• Idempotency at ingestion (unique intent key, e.g. order_shipped:4417 ) kills duplicates from upstream retries — the cheapest place to fix them.
• Collapse keys end-to-end: map one logical stream to FCM collapse_key , APNs apns-collapse-id , Web Push Topic , WNS Tag/Group — so "latest state wins" is enforced by the platform, not just your client.
• Priority mapping table owned by the platform team: message class → {FCM priority, APNs priority + interruption level, Web Push Urgency, TTLs}. Individual product teams request a class; they never set raw priorities. This is how you protect your high-priority quotas.
• Rate limiting on two axes: per-user experience caps (decision layer, e.g. max N promos/day, min gap between pushes) and per-provider throughput shaping (sender workers, token-bucket per connection) to ride large fan-outs without tripping provider limits.

Analytics, observability, and end-to-end tracing

• Propagate one notificationTraceId from intent through the payload to client ack events; join it with your distributed-tracing IDs so "why didn't user X get the push at 09:14" is a query, not an archaeology project.
• Alert on ratios between funnel stages per platform per app version , not absolute counts: accepted→displayed collapse on Android usually means an OEM/channel/permission issue; sent→accepted errors are provider/auth; displayed→opened is a product problem.
• Standard SLOs: p95 intent→accepted latency for the realtime class; token-invalidation lag; DLQ rate; per-campaign uninstall/opt-out deltas (Section 11).

Security and Privacy

Threat model in one paragraph

Push payloads transit third-party infrastructure (Google, Apple, Microsoft, Mozilla), rest on lock screens readable by anyone near the phone, get mirrored to paired watches and connected cars, and are logged by client SDKs. Tokens are bearer-ish identifiers that let anyone holding your server credentials message your users. Registration APIs are an abuse surface. Design for all four.

Payload hygiene

• Never put secrets or sensitive content in the payload: no OTP-in-title for finance apps in sensitive contexts, no medical details, no full card numbers, no auth tokens, no PII beyond what the lock screen should show. The push service can technically see unencrypted native payloads (Web Push is the exception — encrypted by design).
• Pointer pattern for sensitive apps: send an opaque reference ( {type:"secure_msg", id:"m_559201"} ); the client (NSE on iOS, onMessageReceived on Android) fetches or decrypts locally and rewrites the visible text. This is exactly how E2E messengers (Signal-style) render message previews without the plaintext ever touching APNs/FCM.
• Respect platform preview settings: iOS "Show Previews: When Unlocked", Android lock-screen visibility ( VISIBILITY_PRIVATE with a public redacted version). Provide the redacted variant yourself; don't rely on defaults.

Token and credential security

• Treat the APNs .p8 key, FCM service-account JSON, WNS client secret, and VAPID private key as tier-0 secrets: vault-stored, least-privilege, rotated on personnel change, never in client apps or repos. Any one of them = ability to notify (i.e., phish) your entire user base with OS-level credibility.
• Device tokens are personal data (they identify a device/user pair): encrypt at rest, restrict read access, exclude from general logs, and purge per retention policy.
• Authenticated registration: the "register token" endpoint must require an authenticated session and bind token→user server-side. Unauthenticated registration lets an attacker attach their device to a victim's account (silent notification interception) or flood your registry. Rate-limit and anomaly-detect it (many users on one token, rapid token churn per IP).

Consent, GDPR/DPDP, and the preference center

• OS permission ≠ legal consent. Transactional/service messages generally ride legitimate interest or contract; marketing pushes need their own consent under GDPR/ePrivacy — and India's DPDP Act pushes the same direction for Indian users — recorded with timestamp, surface, and wording.
• Ship a preference center : per-category opt-in/out, quiet hours, frequency choices, mapped 1:1 to Android channels and mirrored server-side (so a channel muted on one device suppresses email-push duplicates and applies to the user's other devices where sensible).
• Data-subject rights: deletion must cascade to tokens, notification history, and analytics events; export must include notification consent state. Set retention limits on notification logs (payload metadata, not content, wherever possible).

Abuse prevention and auditability

• Internal misuse is the common incident: a bad segment query pushes a test to production, or a compromised CMS account blasts spam. Mitigate with send authorization (which service/human may send which class to which audience size), staged rollouts with automatic kill switches on opt-out spikes, and a mandatory dry-run/estimate step for audiences above a threshold.
• Audit log every send decision : who/what triggered it, template version, audience definition, counts per funnel stage. This is both your compliance artifact and your best incident-forensics tool.