Request notification permission when users can understand its value. Showing a permission dialog does not guarantee delivery. System permission, in-app preferences and sending records are separate parts of the workflow.
Explain the event, not just the permission
A booking reminder, order update and marketing message create different expectations. State what will be sent, how preferences can change and where information remains available if permission is declined. Avoid pressure or misleading claims.
- Identify relevant events.
- Define reasonable frequency.
- Explain category preferences.
- Provide an alternative way to view information.
- Keep urgent communication planning separate.
Separate operating-system access from app choices
Android's documentation describes runtime notification permission on Android 13 and later. Behaviour depends on platform conditions and user choice; do not assume another platform uses identical rules.
An in-app category may be enabled while system permission is off, or the reverse. Help users understand that distinction.
Handle rejection respectfully
Do not confront users with the same request on every screen. Explain the relevant benefit and provide an appropriate settings path when needed. Check current platform rules before designing repeat requests.
Test account and destination handling
- Allow permission on a fresh install.
- Decline and continue using the app.
- Disable permission in system settings.
- Disable one in-app category.
- Sign out and switch accounts.
- Open a notification and verify authorised access.
A shared device must not reveal a previous user's private record. Avoid unnecessary sensitive lock-screen text and check access before showing details.
Distinguish sent, displayed and read
A server accepting a request is not proof that a person saw it. Define which event your report measures. Review related testing guides and the BE Soft mobile service; bring your event list to a project discussion.
Frequently asked questions
Does permission guarantee delivery?
No. Device, network, account and sending conditions can still affect the result.
Should a rejected request be repeated constantly?
No. Use relevant context and the platform-supported settings route.
