What are Push Notifications (APNs & FCM)?

A push notification is a server-initiated message the platform push services deliver to a device, even when the app is closed. Product teams know push as an engagement channel; this entry covers the delivery machinery — because the machinery explains every quirk product teams complain about. The core fact: your server never talks to the phone. Each mobile OS keeps exactly one battery-optimized, persistent connection to its vendor’s push gateway — APNs (Apple Push Notification service) for Apple devices, FCM for Android — and every notification from every app rides that shared pipe.

Key takeaways

The delivery chain, end to end

1  App asks the OS to register for push
2  Platform push service issues a DEVICE TOKEN (the address)
3  App sends the token to YOUR backend, which stores it
4  Something happens → backend POSTs { token, payload ≤4 KB } to APNs / FCM
5  Push service finds the device's persistent connection → delivers
6  OS shows the notification — or wakes the app briefly for a silent push

FCM's second job: given uploaded APNs credentials, it accepts one request
and re-issues an APNs-compliant request for Apple-bound devices —
one API surface for both platforms. A BaaS abstracts even that away.

Both halves in code — the client registering its address, the backend sending to a channel:

// JavaScript — Cloud Code (cloud/main.js)
// One send call reaches both platform push services
await Parse.Push.send({
  channels: ['scores'], // or `where:` with an Installation query
  data: {
    alert: 'Kickoff! Follow the match live.',
    badge: 'Increment',
    uri: 'app://match/8fk2',
  },
}, { useMasterKey: true });
// Back4app routes to APNs for Apple devices and FCM for Android — one API

// Flutter / Dart — Back4app Flutter SDK
// Register this install for push: token + channels live in an Installation
final installation = await ParseInstallation.currentInstallation();
installation
  ..set('channels', ['scores']) // subscribe to a topic-like channel
  ..set('user', currentUser);   // enables targeting by user later
await installation.save();
// deviceToken and deviceType are captured automatically — your backend
// now addresses this device without touching APNs or FCM directly.

// iOS / Swift — Back4app Swift SDK
// Register this install for push: token + channels live in an Installation
var installation = ParseInstallation.current
installation?.channels = ["scores"] // topic-like channel
installation?.user = currentUser    // enables targeting by user later
try await installation?.save()
// deviceToken and deviceType are captured automatically — your backend
// now addresses this device without touching APNs directly.

// Android / Kotlin — Back4app Android SDK
// Register this install for push: token + channels live in an Installation
val installation = ParseInstallation.getCurrentInstallation()
installation.put("channels", listOf("scores")) // topic-like channel
installation.put("user", ParseUser.getCurrentUser()) // target by user later
installation.saveInBackground()
// deviceToken and deviceType are captured automatically — your backend
// now addresses this device without touching the push services directly.

Device tokens: the address that keeps changing

The token lifecycle is the backend’s real job, and the part explainer pages skip. Register: the OS issues a token per app install. Store: the app syncs it to your backend on every launch — tokens change on reinstall, restore, and data clear, silently. Target: sends address tokens, individually or via the registry. Invalidate: sends to dead tokens come back with specific errors — 410 Gone from APNs, unregistered-token errors from FCM — and FCM ages out tokens unused for roughly nine months. Prune: delete on those errors, immediately. Backends that skip the last step accumulate rotting token tables that waste sends, distort delivery metrics, and slow campaigns — the stale-token problem is boring, cumulative, and the most common real-world push bug.

APNs vs. FCM

The practical consequence of the first row: every cross-platform backend either integrates both services, uses FCM as the single surface (uploading APNs credentials to it), or hands the whole problem to a platform that holds both credential sets — which is where the BaaS section lands.

What push does not promise

The honest contract, assembled in one place. A 200 from the push service means accepted for delivery, not delivered. Offline devices don’t accumulate a faithful queue: APNs keeps only the most recent notification per app; FCM’s queue expires on a TTL. Battery optimizers on Android defer delivery in ways you cannot control; users can silence a channel or the whole app at the OS level, invisibly to your backend. Silent pushes — background wakes with no visible alert — run on a tiny hourly budget and are dropped without error beyond it, per Apple’s own guidance; they are refresh hints, not a sync protocol. The design rule that falls out: push is the tap on the shoulder — the data itself travels through your API when the app opens, and anything that must arrive gets a second channel.

Web push, briefly

Browsers standardized their own chain: the page subscribes via the Push API using your VAPID key pair (RFC 8292 — the server identifies itself with a signed token, no vendor registration required), the browser’s push service returns a subscription (endpoint URL + encryption keys), and your server POSTs encrypted payloads to that endpoint per the Web Push Protocol. A service worker receives the push event and shows the notification — site closed, browser maybe closed on desktop. Each browser vendor runs its own push service; the endpoint URL tells your server where to POST. The honest caveat: on iOS, web push works only for web apps installed to the Home Screen.

Push vs. WebSockets vs. live queries

They are complements with one boundary: the socket serves the user looking at the screen; push reaches the user who put the phone down. Chat apps demonstrate the hybrid daily — messages stream over the connection while the app is open, and the same message becomes a push the moment it isn’t.

Common use cases

• Messages and mentions — the canonical push: someone needs you, the app is closed.
• Transactional alerts — order shipped, ride arriving, payment cleared: one-line summaries deep-linking into the app.
• Time-sensitive triggers — score changes, price alerts, presence-adjacent “X is live” moments.
• Re-engagement — used sparingly, with per-channel opt-outs, or users disable everything.
• Badge and state hints — silent budget spent on nudging the app to refresh before the user opens it.

Should you push? A decision matrix

Limitations and trade-offs

• Delivery is a probability, not a promise. Design flows that survive a missed push; reconcile on app open.
• Permissions are one-shot capital. The OS prompt (explicit on iOS and the web, runtime on modern Android) converts best asked in context — and a denied prompt is nearly irreversible.
• The token registry is a living dataset. Sync on launch, prune on error, or watch deliverability decay quietly.
• Payloads are public-ish. Notifications render on lock screens and travel through third-party infrastructure — summaries and IDs, never secrets.
• Two credential systems, one feature. .p8 keys, console credentials, expiry and rotation — the setup pain is real, once per platform, and exactly what managed layers absorb.

Push on Back4app

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. Back4app’s push service turns the whole chain into data: every install registers itself as an Installation object — device token, platform, channels, and a user pointer captured automatically, as the client tabs show — and one send call addresses channels (topic-style) or any Installation query (“everyone in scores on Android who hasn’t opened the app this week”), with the platform holding your APNs and FCM credentials and routing per device. Sends fire from Cloud Code — an afterSave on Message pushing to the recipient is the hybrid pattern’s fallback half — from scheduled jobs, or from the dashboard console for one-off campaigns. Token hygiene, dual credentials, and per-platform payload quirks become platform behavior; your code decides who and what, not how.