Web/mobile push: Subscription forms
Web push
Effective subscription form
There is two types of subscription forms that can be implemented to your website when enabling web push notifications.
- default (single opt-in)
- custom (double opt-in)
Default subscription form
Comes from the browser itself, it is simple, most common and only requires one click to complete the subscription. You cannot change its appearance, content etc., but you can choose the moment when it should appear and in which sections of your website (see subscription form behavior below).
The language of the form will be automatically changed to the language set in the user browser.
Default, single opt-in subcription form is up to 10 times more effective in accumulating subscribers on your project than custom, double opt in form!
Custom subscription form
You can fully customize your subscription form (even add notifications topic choice to your user!), however it will result in double opt-in subscription process. After accepting the custom form, user will se the default suscription form, which must be accepted as well. The default subscription form is the one that actually saves the subscription.
Subscription form creator
The option can be found in Integration > Web Push (VAPID) > Subscription form
Gives you full customization options for your subscription form, if you decide to go with the custom, double opt-in. You can change the shape, placement, content, fonts, colors, backdrop etc.
You can use Full desktop preview option to see how the form you just created would look like on your website.
You can also decide whether to show the form on mobile devices or not.
Subscription form behavior
Choose the where and when subscription form will be shown on your website.
Go to Integration > Web Push (VAPID) > Settings > Form display
You can define determine on which URLs the subscription form should be shown or hidden.
Bell Widget
The bell widget is another way of promoting signups. After clicking on a bell icon on a page, a pop-up will appear, inviting the user to become a subscriber.
To enable and configure the Bell widget go to the "Integration" tab > Web Push > Bell widget. Here you can add custom texts displayed to the user, the color of the bell icon, and the button text.
Users who have not yet subscribed will see text encouraging them to do so.After signing up, a box will confirm the new subscription, also providing the subscriber with an unsubscribe link.
Mobile push
iOS
System Permission Prompt (OS-Controlled)
On iOS, push notifications can only be authorized through the native Apple permission dialog. This prompt appears when the app calls requestAuthorization.
Important constraints:
- The system prompt cannot be customized
App owners cannot modify:
- Colors or layout
- Button labels (“Allow” / “Don’t Allow”)
- Title or descriptive text
- If a user denies permission, the system prompt cannot be shown again. The user must manually re-enable notifications in the device’s Settings.
Because of these restrictions, the main opportunity lies in preparing the user with a pre-permission experience.
What you can customize?
1. Custom pre-prompt screen
A pre-prompt is an in-app modal, screen, or banner shown before the OS prompt.
This screen is fully customizable and can explain the value of enabling notifications.
Typical elements include:
- Benefits list (“Get delivery updates”, “Receive account alerts”)
- Visuals, icons, or sample notification cards
- Call-to-action: “Enable Notifications”
- Secondary action: “Maybe Later
Upon user acceptance, the app triggers the system permission dialog.
2. Contextual permission requests
Instead of asking on first launch, apps can ask at meaningful moments, such as:
- After a user favorites or follows something
- After placing an order and expecting updates
- During onboarding after key value has been demonstrated
This approach often results in significantly higher opt-in rates.
3. Reminder banners or In-App messages
If a user declines your pre-prompt (not the system prompt), you can show lightweight reminders later in the experience.
Examples:
- A small card in a relevant screen
- A tooltip explaining what notifications enable
- A subtle banner prompting re-engagement
4. Post-denial flows & Deep-link to settings
If the user denied the system prompt:
- The app can detect that permission is denied
- You can present a “How to Enable” screen with a button that links directly to iOS Settings for your app.
This is the only way for the user to re-enable notifications after denial.
Android
Android behavior differs depending on OS version.
Android 13+
Android 13 introduced a dedicated runtime notification permission similar to iOS.
System prompt characteristics:
- Triggered when requesting the POST_NOTIFICATIONS permission
- Cannot be redesigned or reworded
- User choices: typically “Allow” / “Don’t Allow”
Restrictions are similar to iOS: the system dialog is fixed, and your design must occur around it.
Android 12 and below
For older versions:
- Apps are allowed to send notifications by default after installation.
- Users can still disable notifications manually in system settings.
- UX around “enabling” notifications becomes more about education and category selection rather than technical permission.
What you can customize?
1. Custom Pre-Prompt or Explainer Screen
Just like on iOS, you can build a fully custom UI to explain why notifications are helpful. If running on Android 13+, this leads to the system prompt. Below Android 13, it simply toggles a logical preference in your app.
2. Granular Notification Preference Center
Android supports Notification Channels, allowing users to control categories individually.
Common pattern:
- Create an in-app settings screen listing categories (e.g., “Order updates,” “Recommendations,” “Security alerts”).
- When the user enables a category:
- Show your explainer (if permission not granted)
- Trigger the system permission dialog (Android 13+)
- Configure or update notification channels
This gives the user meaningful control and aligns well with platform expectations.
3. Contextual or Event-Driven Requests
Ask at moments that logically justify notifications:
- When the user opts to “track” an item
- After placing an order
- When following a creator or subscribing to a topic
This reinforces value and reduces perceived spam.
4. Post-Denial Re-Enablement Flow
If users deny permissions or turn channels off:
- Show an educational screen explaining the benefits
- Provide a “Open Notification Settings” button linking to system settings
This is the only fully reliable way to let users re-enable them.