Push notifications are a way for a backend service to send a short message to a user’s device without the user explicitly requesting it. The device receives the message through a platform‑provided service – APNs on iOS/macOS, FCM on Android – and the app can react by showing a banner, updating a badge, or silently handling data.
How the Mechanism Works
- App registers for notifications – When the app first runs, it asks the OS for permission. If granted, the OS contacts the platform service and returns a device token (or registration ID). The app sends that token to its own backend.
- Backend stores tokens – The server keeps a mapping of user identifiers to device tokens. When it wants to notify a user, it looks up the token(s).
- Message is sent to the platform service – The backend makes an HTTPS request to APNs/FCM, including the token, payload, and optional headers (priority, expiration, sound, etc.).
- Platform delivers the message – The service maintains a persistent TLS connection to the device. It pushes the payload over that connection, which the OS then hands to the app.
- App handles the payload – If the app is in the foreground, it receives the payload directly. If it’s in the background, the OS may display a notification UI or wake the app for a silent data push.
Persistent Connection Details
- APNs uses HTTP/2 with a single multiplexed connection per provider certificate. The connection stays open for as long as the provider’s server can keep it alive.
- FCM uses a long‑lived XMPP or HTTP v1 connection. Both rely on TCP keep‑alive packets to reduce latency.
Trade‑offs to Discuss
| Aspect | Benefit | Cost / Consideration |
|---|---|---|
| Battery | Push avoids polling, saving power. | Maintaining a persistent TLS connection consumes a small amount of background energy. |
| Latency | Usually sub‑second delivery when the device is online. | If the device is offline or on a poor network, delivery is delayed until it reconnects. |
| Payload Size | Up to 4 KB (APNs) or 2 KB (FCM) for visible notifications; silent pushes can be smaller. | Large payloads require additional data fetches, increasing latency and bandwidth use. |
| Reliability | Platform services handle retries and exponential back‑off. | Some providers (e.g., APNs) may drop messages if the device token is stale or the app is uninstalled. |
| Security | End‑to‑end TLS ensures confidentiality. | Misconfigured certificates can lead to rejected messages or security warnings. |
When answering, acknowledge that the choice of priority (high vs. normal) influences delivery speed and battery impact, and that silent pushes are useful for background syncing but must respect platform limits.
Concrete Example
Imagine you built a ride‑hailing app. When a driver accepts a rider’s request, the backend looks up the rider’s device token and sends a payload like:
{
"aps": {"alert": "Your driver is on the way", "sound": "default"},
"rideId": "12345",
"estimatedArrival": "5 min"
}
APNs delivers this to the rider’s iPhone within seconds. The app shows a banner, updates the badge count, and stores the rideId for later UI updates. If the rider is offline, the notification is stored on APNs and delivered when the device reconnects, respecting the expiration header.
Typical Interviewer Questions
- “Can you walk me through the end‑to‑end flow?” – Summarize registration, token storage, backend request, platform delivery, and client handling.
- “What are the limits on payload size and why do they exist?” – Mention APNs (4 KB) and FCM (2 KB) limits, motivated by network efficiency and battery impact.
- “How would you handle a user who disables notifications?” – Explain fallback strategies like in‑app messaging or email, and the importance of respecting user consent.
- “What are the security considerations?” – Discuss TLS, certificate management, token revocation, and avoiding sensitive data in the payload.
- “How do you ensure delivery reliability across platforms?” – Talk about handling token expiration, using exponential back‑off, and monitoring delivery reports.
60‑Second Spoken Answer
"Push notifications are server‑initiated messages delivered to a device via a platform service like APNs or FCM. The app first registers and receives a device token, which it sends to its backend. When the backend wants to notify the user, it posts a payload to the platform using that token. The platform maintains a persistent TLS connection to the device and pushes the payload, which the OS either displays as a banner or hands to the app for silent processing. The main trade‑offs are battery usage versus latency, payload size limits, and handling token revocation. For example, a ride‑hailing app can notify a rider the moment a driver accepts the request, updating the UI within seconds. In an interview you’d discuss registration, delivery mechanics, limits, security, and fallback strategies."
How to Practice This
- Record yourself – Use Call Assistant to capture your spoken answer, then review the transcript for filler words and timing.
- Simulate follow‑ups – Have a friend ask a typical interview question (e.g., about payload limits) and let Call Assistant keep the conversation on topic while you expand your story.
- Ground the story in your resume – Upload a project description to the Call Assistant dashboard and rehearse linking the push‑notification example to that specific experience.
FAQ
- What is the difference between a visible and a silent push notification? Visible pushes contain an alert, sound, or badge that the OS shows to the user. Silent pushes carry only data; the app receives it in the background to update state without user interruption.
- Can push notifications be used on macOS? Yes. macOS uses the same APNs infrastructure as iOS, and apps can register for notifications to show banners or update dock badges.
- How do you handle token expiration? The platform service returns an error when a token is invalid. Your backend should delete stale tokens and request a fresh registration from the app.
- Why not just poll the server for updates? Polling consumes more battery and network bandwidth because the client must repeatedly open connections, whereas push leverages a single persistent channel managed by the OS.
Frequently asked questions
What is the difference between a visible and a silent push notification?
Visible pushes contain an alert, sound, or badge that the OS displays to the user. Silent pushes carry only data, allowing the app to update its state in the background without showing a UI element.
Can push notifications be used on macOS?
Yes. macOS uses the same Apple Push Notification service (APNs) as iOS, and apps can register for notifications to show banners or update dock badges.
How do you handle token expiration?
When APNs or FCM returns an error indicating an invalid token, the backend should remove that token from its store and prompt the app to re‑register, ensuring future messages reach a valid device.
Why not just poll the server for updates?
Polling requires the client to repeatedly open connections, which drains battery and uses more bandwidth. Push leverages a persistent, OS‑managed channel that delivers messages only when needed, making it more efficient.
#concept#push notifications#interview#mobile#backend