What are push notifications?
Push notifications re-engage users with messages delivered even when the app is closed. Local notifications are scheduled by the app itself; remote (push) notifications are sent from your server through Apple and Google's delivery services to a device token your app registers.
Why it matters
Notifications drive retention, but they involve a multi-step pipeline — permission, token registration, server delivery, platform services — with many failure points. Knowing how the whole chain works is essential to actually getting a notification to appear, and to not annoying users into uninstalling.
What to learn
- Local versus remote notifications
- Registering for a push token
- The delivery path through APNs and FCM
- Sending from your server
- Notification permissions and opt-in timing
- Handling a tapped notification (deep link)
- Foreground versus background handling
Common pitfall
Sending too many low-value notifications. Nothing drives uninstalls and notification opt-outs faster than spam. Send notifications that are timely and genuinely useful to that user, respect their preferences, and give granular controls — frequency and relevance matter more than volume.
Resources
Primary (free):
- Expo — Push notifications · docs
- Firebase — Cloud Messaging · docs
- Apple — User notifications · docs
Practice
Wire up notifications end to end: request permission, register for a push token, send a test push (Expo's tool works), and handle a tap that deep-links to a relevant screen. Also schedule one local notification. Done when a tapped push opens the right screen.
Outcomes
- Distinguish local and remote notifications.
- Register a device for a push token.
- Send a push and handle the tap with a deep link.
- Respect users by sending only valuable notifications.