- Who is this for?
- Mobile developers implementing notifications and deep links.
- Before you start
- FCM/APNs configuration, user sessions and server-held provider credentials.
1. Model devices separately
A user can own several devices and a device can change accounts. Track user mapping, platform, environment and update time. Refresh backend registration when the token changes and remove the old association on logout. Shared-device cross-account leakage is an essential test.
2. Minimize notification data
Avoid sensitive content on lock screens. Use the notification to invite an authenticated fetch. A deep-linked identifier is not permission to view a record. Provide a clear state for removed or inaccessible resources.
3. Queue durable sending work
Persist the event and queue sends instead of calling every device inside a user request. Handle duplicate events deliberately. Retry transient limits with bounded backoff and jitter; do not endlessly retry permanent failures.
| Outcome | Action |
|---|---|
| Provider accepted | Record acceptance, not guaranteed delivery |
| Transient error | Bounded backoff |
| Invalid token | Clean registration |
| Credential error | Fix configuration without logging secrets |
4. Distinguish acceptance and engagement
Provider acceptance, device delivery and user opening are separate stages. Use metrics actually available from the platform. Missing delivery visibility is not 100% success. Track queue age, invalid tokens and send errors without storing message content or tokens in analytics.
5. Test lifecycle and permissions
Try denied permission, a closed app, renewed tokens and a disconnected device. Deep-link navigation may need to wait for sign-in. FCM’s no-cost messaging does not make your queue, backend or other external services free.
6. Verify release configuration
Separate development and production credentials. Keep provider keys server-side. Apply duplicate-alert, quiet-hour and opt-out policies deliberately. Do not assume transactional and marketing notifications share the same permission requirements.
- Test token change and logout.
- Authorize the deep-linked resource.
- Separate transient and permanent errors.
- Allow state refresh without a notification.
Action summary
- Manage token lifecycle.
- Queue sends with bounded retry.
- Fetch authenticated state after an alert.
Common questions
Does acceptance guarantee delivery?
No. Acceptance, visible delivery and user opening are separate stages.
Are tokens permanent?
No. Implement renewal and backend registration updates.
Sources and scope
Technical references are listed below. Examples illustrate implementation in your own environment; they are not customer benchmarks or claims of live Uygulama Cloud services. Check the current provider documentation before applying settings.
Sources checked: