What this prompt does
This prompt has the AI act as a senior mobile engineer and return working server and client code for the full push notification flow, not a high-level overview. You provide the [platform], the [service], the [backend] stack, and the primary [use_case], and it returns server code, client code, and an example payload, each in its own fenced block.
The five deliverables span every layer where push breaks at once: iOS and Android permission requests with a sensible opt-in UX and a re-ask path after a soft deny; device-token registration to your backend with refresh and de-duplication so one user does not collect stale tokens; topic subscription and user segmentation plus both scheduled and event-triggered sends for your [use_case]; rich payloads with images and action buttons and deep linking that routes correctly from cold start and background; and delivery and open-rate analytics with guidance on testing the whole loop on a real device. The structure works because push fails silently at the token, payload, deep link, and cold-start layers, and the prompt forces each one to be handled.
When to use it
- You are adding push notifications and need both the backend send logic and the client handling.
- You keep collecting stale device tokens and need refresh and de-duplication.
- You want topic-based segmentation plus scheduled and event-triggered sends.
- You need deep links that route correctly when the app is tapped from a killed state.
- You want delivery and open-rate analytics rather than fire-and-forget sends.
Example output
You get three fenced blocks: server code that registers and de-duplicates device tokens and sends scheduled and event-triggered notifications through your [service], client code handling permissions, the re-ask path, and deep-link routing from cold and background states, and an example rich payload with an image, action buttons, and the deep-link target for your [use_case].
Pro tips
- Always test the tap-from-killed-app path; it routes differently from a backgrounded app and breaks silently in production.
- Get token refresh and de-duplication right early - stale tokens are why a user's notifications quietly stop arriving.
- Match
[service]to your real provider so the send code and payload format are correct as written. - Set
[use_case]specifically (order updates, re-engagement) so the segmentation and trigger logic fit your actual sends. - Design the soft-deny re-ask path deliberately; if you burn the OS permission prompt, you cannot ask again natively.
- Match
[backend]to your stack so the token-registration endpoint and send worker drop into your codebase. - Verify deep links route correctly from a backgrounded app too, not only cold start; the two paths hit different lifecycle hooks and one often works while the other does not.
- Track open rate alongside delivery, since a payload that delivers but never gets tapped usually means the copy or timing is wrong, not the plumbing.
