Push Notifications

Messages sent from a server to a user's device that appear as alerts, badges, or sounds even when the app is not open.

Category: Mobile Development (also: Web Development, UX)

Author: Atomic Glue Editorial Team

## Definition

Push Notifications are server-initiated messages delivered to a user's device through platform-specific push services. They appear as banners, badges, sounds, or lock-screen alerts. Unlike pull-based polling, push notifications are event-driven: the server sends data only when something happens. They are the most effective tool for re-engaging users, with open rates 10x higher than email, but they must be used responsibly to avoid notification fatigue and app uninstalls.

## Platform Push Services

Each platform has its own push delivery infrastructure. **Apple Push Notification service (APNs)**: Delivers notifications to iOS, iPadOS, macOS, watchOS, and tvOS. Requires a TLS connection and a provider certificate or token. **Firebase Cloud Messaging (FCM)**: Delivers to Android devices and also works for iOS as a relay to APNs. FCM handles device token management, message prioritization, and delivery analytics. **Web Push Protocol**: Uses the Push API and service workers to deliver notifications to browsers on desktop and mobile.

## Types of Push Notifications

There are several notification types. **Local notifications**: Scheduled by the app itself, no server required. Alarms, reminders, timers. **Remote/push notifications**: Server-initiated. **Silent push**: No alert shown; wakes the app to perform a background data refresh. **Rich notifications**: Include images, buttons, input fields, and custom UI. **Interactive notifications**: Allow users to take actions (reply, mark as read, delete) without opening the app.

## Best Practices and Permissions

Push notifications require explicit user permission on both iOS and Android. iOS prompts once automatically; Android shows a prompt but the user can configure it later. Ask for permission in context, not at first launch. A user who grants push permission is signaling high intent. Respect that by sending relevant, timely, and not excessive notifications. Badge counts, sound, and alert styles should be customizable in settings. Measure opt-out rates religiously. If more than 30% of users disable notifications, your strategy is wrong.

## In code

// FCM: Sending a push notification via Admin SDK
const admin = require('firebase-admin');

const message = {
  notification: {
    title: 'Your order shipped',
    body: 'Track your package now'
  },
  data: {
    orderId: '12345',
    type: 'shipping_update'
  },
  token: userDeviceToken
};

admin.messaging().send(message)
  .then((response) => console.log('Sent:', response))
  .catch((error) => console.error('Error:', error));

## Common questions

Q: How do push notifications work when the app is closed?

A: Each OS maintains a persistent connection to its push service. When a push arrives, the OS handles display, sound, and badge updates. If the app has background execution entitlement (iOS) or a foreground service (Android), the app gets a chance to process the notification before display.

Q: Can I send push notifications to users who uninstalled my app?

A: No. Both APNs and FCM remove invalid tokens from their systems. You'll receive an error response indicating the token is invalid, and you should remove it from your database.

## Key takeaways

• Push notifications are server-initiated messages delivered through platform push services.
• APNs handles iOS; FCM handles Android (and can relay to APNs for iOS).
• Always ask for permission in context, never at first launch.
• Rich and interactive notifications improve engagement without requiring app opens.
• Monitor opt-out rates and send notifications users actually want.

## Related entries

• [Progressive Web App (PWA)](atomicglue.co/glossary/progressive-web-app-pwa-front-end)
• [Offline Mode](atomicglue.co/glossary/offline-mode)

Last updated June 2025. Permalink: atomicglue.co/glossary/push-notifications