Wires native mobile push end to end on APNs and FCM - device-token lifecycle, permission priming and prompt timing, alert and silent payloads, the server send path, and tap routing in all app states. Use when someone says "add push to our app", "the notification never arrives", "how do I handle FCM token refresh", or is wiring the .p8 or service-account sender and handling notification taps. Do NOT use for writing the notification text and message strategy - use push-notification-copy instead; not for web/browser push (Web Push/VAPID), in-app banners, or platform notification dashboards; and hand navigation from a tapped payload into a specific screen to a deep-link router.
Click to play with sound.
---
name: Push Notification Wirer
description: Wires native mobile push end to end on APNs and FCM - device-token lifecycle, permission priming and prompt timing, alert and silent payloads, the server send path, and tap routing in all app states. Use when someone says "add push to our app", "the notification never arrives", "how do I handle FCM token refresh", or is wiring the .p8 or service-account sender and handling notification taps. Do NOT use for writing the notification text and message strategy - use push-notification-copy instead; not for web/browser push (Web Push/VAPID), in-app banners, or platform notification dashboards; and hand navigation from a tapped payload into a specific screen to a deep-link router.
---
# Push Notification Wirer
Wire native iOS (APNs) and Android (FCM) push as a verified pipeline: every hop fails silently - a wrong key, stale token, backgrounded app, or missing entitlement all produce "nothing happened" with no error - so prove each hop instead of assuming it. The costly failure is shipping push that works on the developer's device for a week, then silently decays as tokens rotate and permissions are denied.
## Operating procedure
### Step 1: Gather inputs
1. Platforms in scope (iOS, Android, both) and minimum OS versions - Android 13+ adds the POST_NOTIFICATIONS runtime permission.
2. Notification types planned: user-visible alerts, silent/background data pushes, or both. Silent push has hard throttling constraints; flag any feature that depends on guaranteed silent delivery as a design risk now.
3. Server stack and where tokens will be stored (must key by user AND device).
4. The value moment that will justify the permission prompt (order placed, message sent, price alert created). If nobody can name one, resolve that before wiring the prompt.
5. Who owns the message content - route copy, tone, and send-time strategy to push-notification-copy.
### Step 2: Register and persist the token
Register for remote notifications, capture the device token (APNs) or registration token (FCM), and POST it to the server keyed by user AND device. Send it on every launch and on the rotation callback (didRegisterForRemoteNotifications / FCM onNewToken) - never only once at signup. Tokens change on reinstall, restore, and refresh.
### Step 3: Run the token lifecycle, not just registration
Apply these lifecycle rules server-side: