Sharing push notification logic between apps

Separate the event from the delivery channel

Start with events such as a new message or a changed reservation, then define the recipient and delivery conditions. Implementing this separately in each app makes the rules drift.

A shared event can carry an identifier, type, recipient, related-record identifier and expiry. Platform delivery settings and visible text can be derived from that event. This keeps business decisions reusable when another channel is introduced.

Decide whether the event needs immediate attention, belongs only in an in-app inbox or can be disabled by category. A durable inbox entry and a transient device notification serve different purposes.

Manage device registrations independently of accounts

One person may use several devices, and one device may switch accounts. Model account membership and app-instance registration separately. Define updates for sign-in, sign-out, reinstallation and registration changes.

On shared devices, remove the previous account association from server targeting when the session ends. Distinguish operating-system notification permission from a subscription managed by the service.

Firebase registration guidance recommends keeping registrations fresh and removing invalid targets. Verify the registration mechanism for the SDK version in use and retain timestamps that help operations identify stale records.

Handle duplicates and stale notifications

Retries and repeated jobs can process the same event more than once. Use the event identifier to define duplicate handling for delivery jobs and inbox records. A delayed message also needs an expiry decision, not an automatic resend forever.

For example, a reminder delivered after an appointment starts may be misleading. Expiration and a check of the latest booking state are possible responses.

Keep submission, provider response and failure reason distinct in operational records. Name metrics carefully: a delivery service accepting a request does not establish that someone saw or read the notification.

Verify the destination after a tap

A tap should lead to the relevant task, but the session may have expired, the record may be gone or permissions may have changed. Fetch current data and authorize the current user before opening the destination.

Try taps while the app is active, in the background and closed. Include returning to the destination after login and reopening an already handled notification. Verify delivery and permission prompts on each platform, while testing event classification and destination rules as shared logic.

This makes the boundary explicit: reuse the business rules and verify platform delivery conditions independently.