Pushlane: iOS Push Permission for Subscription Apps

The iOS notification prompt is a product decision before it is a growth tactic. The person sees a system question with a lasting consequence, often before your team knows whether notifications will be useful to them. Asking too early spends that decision without context. Asking only after a paywall can make permission feel like another monetization demand.

A better prompt follows a value the person has just created: a scheduled workout, a tracked budget, a saved lesson time or a report that will finish later. The app can name the notification, explain why it matters and ask only when it can keep the promise.

This guide designs that sequence for an iOS subscription app using Pushlane. It does not offer a universal opt-in benchmark because the product, audience, country and prompt context all change the result.

Know what iOS does with the first request

Apple requires permission for alerts, sounds and badges. The first explicit call to requestAuthorization prompts the person and records the response. Calling it again does not display the system prompt a second time. Apple's official permission documentation recommends requesting authorization in a context that makes the benefit understandable.

That creates two product requirements:

1. Do not call the system API until your interface has a justified moment.
2. Have a useful denied-state experience because you cannot simply ask again tomorrow.

Permission is also not permanent. People can change notification settings in iOS. Check current UNNotificationSettings when notification-dependent features are used, rather than treating an old local flag as authoritative.

Apple supports provisional authorization for quiet trial notifications. It is a distinct product choice, not a way to disguise an explicit prompt. Pushlane's current Expo drop-in requests standard authorization and does not implement provisional permission. If you build a native provisional path, test how quiet delivery supports a real user job before adopting it.

Separate the pre-prompt from the system prompt

A pre-prompt is your own screen. It can explain the benefit and offer "Not now" without consuming the iOS decision. It must not imitate the Apple system alert or pressure the person into tapping Allow.

The sequence should be:

user completes a meaningful setup action
  -> app explains the specific notification
  -> user chooses Enable or Not now
  -> Enable calls the iOS authorization API
  -> granted registers the APNs token with Pushlane
  -> denied keeps the product usable and records no false reachability

Good pre-prompt copy names the event and the control:

Get a reminder before your planned workout

We can notify you at the time you selected. You can change this anytime in Settings.

Weak copy describes a company goal:

Enable notifications so you never miss our updates.

"Updates" gives no reason to interrupt the person. "Never miss" also promises more than the app can control because Focus modes, notification summaries and device settings influence presentation.

Choose a moment connected to value

The best timing is usually after the person creates something worth notifying them about.

This is stronger than "after screen three" because the event has meaning even if the onboarding design changes.

Do not automatically request permission on first launch. The person has no evidence of value. Do not trigger it immediately after purchase merely because you now know the user pays. A purchase does not create blanket permission to interrupt.

If a subscription feature genuinely depends on a timely alert, explain that dependency when the user enables the feature. Apple says push must not be required for app functionality, so keep a non-push path such as an in-app status screen where practical. Review Apple's current App Review Guidelines before tying notifications to access or marketing.

Coordinate the prompt with paywall and trial state

Subscription apps often encounter three early events close together: onboarding completion, paywall view and trial start. Do not let all three compete for attention.

Before the paywall, ask only if the person has already configured a notification-worthy feature. The prompt should not act as a hidden prerequisite for seeing pricing.

After a paywall dismissal, continue the product path. A push request that immediately follows can feel like an attempt to chase the user who declined to buy. Wait until they complete or schedule something useful.

After a trial starts, confirm access and help the person activate before asking for another system decision. If notification permission directly enables the chosen use case, the pre-prompt can follow that setup action. Avoid stacking the App Store purchase sheet, notification prompt and tracking authorization prompt in one uninterrupted sequence.

RevenueCat subscription events can tell Pushlane when the trial or purchase state changes, but the permission request itself belongs in the app interface. Do not attempt to launch the iOS system prompt from a server push flow.

Implement a small permission state machine

Model at least these states:

• notDetermined: the system prompt has not been answered;
• authorized: alerts are allowed according to current settings;
• provisional: quiet delivery is authorized, if your native implementation uses it;
• denied: the app cannot display the system prompt again;
• changed settings: individual alert, sound or badge settings may differ.

At the relevant product moment, read the current settings.

let settings = await UNUserNotificationCenter.current().notificationSettings()

switch settings.authorizationStatus {
case .notDetermined:
    // Show your contextual pre-prompt first.
case .authorized, .provisional:
    // Register for remote notifications and enable the feature UI.
case .denied:
    // Explain how to open Settings only when the feature needs it.
default:
    break
}

The exact implementation should use your app's concurrency and state-management conventions. The important behavior is that the status comes from iOS.

When authorization is granted, register for remote notifications and forward the current APNs token to Pushlane after Pushlane.identify(). Apple's APNs registration guide explains that the token identifies the app-device pair and should be sent to the provider server.

Handle "Not now" and "Don't Allow" differently

"Not now" on your pre-prompt means the system has not been asked. Respect a cooling-off period and wait for another genuinely relevant product moment. Do not show the pre-prompt on every launch.

"Don't Allow" on the iOS prompt means the system decision is denied. Stop presenting fake retry buttons. When a notification-dependent feature is later selected, explain the benefit and provide a button that opens the app's iOS Settings page. The button label should say what it does, such as "Open iOS Settings", not "Enable" if the app cannot enable permission itself.

The rest of the app should remain functional. Use in-app inboxes, status screens or manual refresh for information the person still needs. A denied notification permission is a preference, not an error state to clear.

Do not mark a denied user as reachable in campaign reporting. Pushlane registers the device only after the permission and token path succeeds. A later send without an active APNs device should be recorded as suppressed, not delivered.

Keep marketing consent and system permission distinct

iOS authorization answers whether the operating system may present notifications. Your app's marketing preference answers which categories the person wants. They are related but not identical.

A user can allow iOS notifications and opt out of marketing while retaining necessary account alerts. Pushlane supports explicit marketing consent changes through its SDK and drop-in clients. Record a preference only when the person makes that choice in your settings UI.

Do not interpret an iOS Allow tap as consent for every promotional campaign. Describe categories clearly, honor opt-outs and make the settings path easy to find.

Test the prompt as a user journey

Resetting permission during development is not enough. Test these paths on a physical iPhone:

1. Fresh install, relevant product action, pre-prompt Enable, iOS Allow, token registration and test push.
2. Fresh install, pre-prompt Not now, continued product use, later relevant opportunity.
3. Fresh install, iOS Don't Allow, later feature request and accurate Settings explanation.
4. Permission granted, then disabled in iOS Settings while the app is backgrounded.
5. Alerts disabled while badge or sound settings differ.
6. Logout after authorization and login as another account on the same device.
7. App reinstall or token refresh, followed by successful re-registration.
8. A notification tap from foreground, background and terminated states.

Check that no screen promises a notification when current settings make it impossible. Check that the deep link works even after authentication expires.

Measure the whole permission funnel

Track product events around the experience without treating them as proof of consent:

• eligible product moment reached;
• pre-prompt viewed;
• pre-prompt Enable or Not now;
• iOS authorization status after the request;
• APNs token registered successfully;
• first useful notification sent and interacted with;
• notification settings changed later;
• product outcome connected to the notification job.

The denominator for system opt-in should be people who actually saw the system prompt, not every install. The denominator for reachability should require a valid registered device, not only an Allow response.

Compare prompt moments only when the underlying audience and value proposition are comparable. A workout reminder and a generic marketing request are different products, even if both call the same system API.

Earn the prompt with a concrete promise

The system alert is the final step, not the message. First give the person a reason to want a specific notification. Then ask clearly, register honestly and make denial survivable.

Pushlane can automate the lifecycle messages that follow, but it cannot create the value proposition for permission. Start with one notification-worthy product moment and verify the entire iOS path in the Pushlane iOS subscription guide.