Visit Website →
← Back to blog

iOS Push Notifications for Ecommerce: Quiet Alerts Before the One Ask

October 14, 2026
iOS Push Notifications for Ecommerce: Quiet Alerts Before the One Ask

Call UNUserNotificationCenter.requestAuthorization(options:completionHandler:) to trigger the system dialog, but don't lead with it. The highest-converting sequence starts with provisional notifications for quiet delivery, adds an in-app soft prompt at a value moment, and only then shows the one-shot system prompt. For short-lived flows like a checkout, an App Clip can request an 8-hour ephemeral notification window instead.

TL;DR:

  • Check authorization status before acting, because Apple shows the native permission prompt only once per install; ask after a clear value moment.
  • Provisional access delivers notifications quietly to Notification Center without showing the system dialog, letting users assess actual messages before choosing full authorization.
  • For checkout visitors without the full app, App Clips can request ephemeral notification access lasting up to 8 hours after launch.
  • After a denial, skip another permission request and show a relevant in app message with a direct link to notification settings.
  • Test remote delivery on a physical device, because the iOS Simulator does not support it reliably; reinstall between runs to reset permission status.
StorePush
storepush.io
Reach Shoppers After They Leave
StorePush sends push notifications to shoppers’ lock screens, helping ecommerce businesses re-engage visitors who leave without purchasing, even without collected contact details.
Visit StorePush

Table of Contents

How iOS's permission model for push notifications actually works

Every iOS push flow runs through the same gatekeeper: UNUserNotificationCenter. Before any notification reaches a lock screen, you call requestAuthorization(options:completionHandler:), and the options you pass (alert, sound, badge, provisional) tell the system what kind of access you're asking for. According to Apple's developer documentation, this call triggers the native system prompt, and the system saves whatever the user decides.

That last part matters more than most teams realize. The prompt is not a renewable resource. Apple's own guidance confirms that the system prompt only appears once per install; calling requestAuthorization again after a user has made a choice does nothing but return the cached result. If someone taps "Don't Allow," you don't get a second shot at the native dialog. You get Settings, or you get nothing.

Authorization settles into one of four states:

  • .notDetermined: the user has never been asked, so you can still show the system prompt.
  • .provisional: the user is receiving quiet, Notification Center only delivery without having seen the system dialog.
  • .authorized: full delivery, including banners, sounds, and lock screen alerts.
  • .denied: the system prompt is burned, and only a trip to Settings can change it.

You can check which state a user is in at any time by calling getNotificationSettings, and you should do this before deciding whether to show a soft prompt, request provisional access, or skip straight to scheduling a notification. Pair this with category registration at launch, inside application:didFinishLaunchingWithOptions:, as described in Apple's remote notification programming guide. Categories define the actions a notification can present (reply, view, dismiss), and registering them late can cause actions to silently fail on delivery.

The practical takeaway: treat the system prompt like a single bullet. Everything you do before firing it, provisional delivery, in-app messaging, timing, should be aimed at making that one shot count.

When and how to request permission without wasting it

Asking on first launch is the fastest way to burn your one shot. A user who just opened your app for the first time has no context for why notifications matter to them, so the default answer is "Don't Allow." Wait for a moment where the value is obvious: right after onboarding completes, right after a purchase confirms, or right after someone adds an item to a cart they might abandon.

  1. Pick the trigger event. Choose a moment tied to a concrete benefit, like order tracking or a saved cart, not an arbitrary screen or timer.
  2. Show a soft prompt first. Build an in-app modal or banner that explains what the user gets (restock alerts, shipping updates, price drops) and ends with a clear "Enable Notifications" button.
  3. Only call requestAuthorization when they tap through. The soft prompt itself consumes nothing; only the button action fires the real system dialog.
  4. Let the soft prompt reappear. Since it's your own UI, you can show it again on a later value moment if the user dismissed it the first time, as long as you haven't yet triggered the system prompt.
  5. Space re-asks by context, not calendar days. A second soft prompt after a second cart addition tends to land better than one scheduled by a fixed interval.

OneSignal's guidance on prompting for push permissions backs this sequencing: combining provisional notifications, reasonable in-app soft prompts, and a programmatic system prompt is the standard pattern for lifting iOS opt-in rates. Because the native dialog can't be restyled or reworded, the soft prompt is your only real opportunity to make the case before the user sees Apple's generic "Would Like to Send You Notifications" text.

Pro Tip: Write your soft prompt copy around a specific outcome ("Get notified when your order ships") instead of a generic one ("Stay updated"); specificity is what gets the tap.

For a deeper breakdown of opt-in tactics across both major mobile platforms, our push notification opt-in guide walks through additional trigger patterns worth testing.

Provisional notifications and App Clip ephemeral permissions

Two mechanisms let you reach users without spending the one-shot system prompt right away, and they solve different problems.

Provisional notifications request quiet, Notification Center only delivery. You pass the .provisional option into requestAuthorization, and iOS delivers notifications without ever showing the system dialog. The user sees real notifications land quietly, decides whether they're useful, and can upgrade or silence them from Notification Center directly. OneSignal's provisional notification documentation describes this as letting users judge your notifications by their actual content rather than a one-line system prompt, which tends to produce a more informed opt-in decision later.

App Clip ephemeral notifications solve a different problem: reaching someone who never installed your full app. Add NSAppClipRequestEphemeralUserNotification set to YES in the App Clip's Info.plist, and the clip can request a temporary notification permission that stays active for up to 8 hours after launch, according to Apple's WWDC 2020 session on App Clips. That's enough runway to follow up on a checkout someone started but didn't finish, without asking them to download anything.

Two paths for quiet and temporary notifications

One App Clip ephemeral window lasts up to 8 hours, which lines up well with typical cart abandonment recovery timing: long enough to catch someone after they've closed the tab, short enough that the offer still feels current.

A pattern worth testing in sequence:

  • Request provisional access immediately for low-friction, quiet reach.
  • Show a soft prompt after the user engages with a provisional notification, since they've already seen the value.
  • Use an App Clip's ephemeral window for short, high-intent flows like checkout, where installing a full app would be a bigger ask than the purchase itself.

Our guide to lock screen notifications via App Clips goes deeper into configuring this flow for checkout-specific use cases.

Concrete implementation: Swift code, APNs, and device tokens

The sequence that holds up in production looks like this: call requestAuthorization, then registerForRemoteNotifications, then handle the token in didRegisterForRemoteNotificationsWithDeviceToken. Skipping straight to registration without checking authorization status first is a common source of silent failures, since a token registered under .denied is useless for alert delivery.

Before firing any prompt, branch your logic on the current state:

  • Call getNotificationSettings first and read the authorizationStatus property.
  • If .notDetermined, show your soft prompt and let the user trigger requestAuthorization.
  • If .provisional, consider surfacing a soft prompt to upgrade to full authorization once the user has seen real notifications.
  • If .authorized, proceed straight to registerForRemoteNotifications.
  • If .denied, skip the prompt entirely and route toward a Settings deep link instead.

On the server side, APNs authentication has moved almost entirely to token-based auth keys (.p8 files) rather than the older certificate-based model, since a single key can serve both development and production environments and doesn't expire on the same yearly cycle certificates do. Whichever method you use, your App ID needs the push notification entitlement enabled in your provisioning profile, and your push provider (whether that's your own server or a third-party SDK) needs the resulting device token to address notifications to that specific installation.

A few setup details trip up teams consistently:

  • Device tokens change across reinstalls and OS updates, so your backend needs to handle token refresh gracefully rather than treating tokens as permanent identifiers.
  • Push notifications don't work in the iOS Simulator for remote delivery testing; you need a physical device registered with a valid provisioning profile.
  • App Clips have their own bundle identifier and entitlements separate from the parent app, so ephemeral notification permissions and standard app permissions are tracked independently. A user authorizing the full app doesn't automatically authorize the App Clip, and vice versa.
  • Categories and actions registered in the main app don't carry over to an App Clip target; each needs its own registration if you want interactive notifications in both contexts.

Testing, denied permissions, and getting users back to Settings

Testing the system prompt reliably means uninstalling and reinstalling the app on a physical device, since Apple doesn't expose a way to reset authorization status from within a running app, and the Simulator can't fully replicate remote notification delivery.

  1. Uninstall and reinstall between test runs to reset .notDetermined status and see the system prompt again.
  2. Test on a real device, since push tokens and delivery don't work reliably in the Simulator.
  3. Build a denied-state fallback screen that explains what the user is missing and includes a button that deep links into your app's notification settings page.
  4. Wire up a Settings redirect, similar to the requestPermission(fallbackToSettings: true) helper pattern OneSignal documents, so a denied user has one tap to re-enable rather than a manual hunt through iOS Settings.
  5. Instrument the full funnel: track prompt impressions, allow rate, provisional-to-authorized conversions, and eventual push-driven conversions, so you know which stage is leaking users.

Without that instrumentation, you're optimizing blind. A low allow rate could mean bad timing, weak soft prompt copy, or a trigger event that doesn't feel valuable enough, and you can't tell which without the data broken out by stage.

Practical best practices to increase iOS push opt-in rates

The tactics that move the needle tend to stack rather than compete. Provisional notifications get you quiet reach immediately. A soft prompt, shown only after a meaningful action, sets up context before the system dialog appears. The system prompt itself, saved for a genuine value moment, closes the loop.

  • Lead with provisional access for day-one reach, then earn full authorization through demonstrated value.
  • Write soft prompt copy around a specific benefit: "Know the moment your order ships" converts better than "Turn on notifications."
  • Trigger the soft prompt after cart activity, order placement, or wishlist saves, not on app launch.
  • Track the entire funnel, from prompt impression through allow rate through actual push opens through attributed conversion, so you can see where the drop-off happens.
  • For checkout-specific flows, test an App Clip's ephemeral window against your standard soft prompt sequence and compare conversion within the 8-hour window.

Pro Tip: Run your soft prompt copy as an A/B test before you ever touch the system dialog; since the system prompt is fixed text you can't edit, your soft prompt is the only lever you actually control.

Timing the send itself matters almost as much as the opt-in moment. Our guide to push notification timing covers time zone handling and scheduling details that affect whether an authorized user actually engages once you have permission.

Apple's App Store Review Guidelines require that push notifications never be used for advertising, marketing, or direct response campaigns unless the user has explicitly opted in, and that users must be able to opt out at any time through Settings. This is enforced at the permission layer: since requestAuthorization is the only sanctioned path to enabling alerts, there's no way to bypass user consent and still pass review.

Provisional notifications don't exempt you from this standard. Quiet delivery to Notification Center still requires the user to have taken no action blocking it, and users can silence a provisional sender at any time directly from a delivered notification, which Apple treats as an implicit opt-out.

Beyond Apple's own rules, broader privacy frameworks shape how you talk about notifications in your soft prompts and marketing. The App Tracking Transparency (ATT) framework governs cross-app tracking and IDFA access, not notification permission directly, but the two often get requested close together in onboarding flows. Bundling an ATT prompt with a push soft prompt tends to depress both acceptance rates, since users read back-to-back permission requests as a single invasive moment rather than two separate asks. Separating them, with push tied to a clear value moment and ATT requested in its own context, tends to perform better for both.

If your notifications support ecommerce messaging like cart reminders or price drops, keep the content factual and tied to the user's own activity rather than generic promotional blasts, which keeps you aligned with both Apple's guidelines and general consumer protection expectations around unsolicited marketing messages.

Getting users back after they deny push permissions

A denied system prompt isn't the end of the relationship, just the end of that particular path. Since Apple won't re-show the native dialog, every re-engagement strategy for denied users has to route through either Settings or a different channel entirely.

The most direct approach is an in-app message that appears at a relevant moment (viewing an order, revisiting a saved cart) explaining specifically what the user is missing, with a button that deep links straight into your app's notification settings page in iOS Settings. Keep that message tied to something concrete happening right then, not a generic reminder that notifications exist.

For users who don't take that step, email and SMS remain the fallback channels, provided you collected that contact information elsewhere in the funnel. That said, email has its own ceiling: messages land in spam, get buried in a crowded inbox, or simply go unopened, which is part of why lock-screen reach carries different weight than another inbox message competing for attention. If you're building out opt-in across channels, our partner guide on growing an email list covers complementary tactics worth pairing with push.

For shoppers who never installed your app at all, an App Clip's ephemeral notification window offers a separate path back in, since it doesn't depend on the main app's authorization status at all.

Author perspective: lessons from ecommerce push opt-in funnels

The funnel that consistently outperforms a single system prompt is provisional access first, a soft prompt tied to a cart or purchase event second, and the system dialog last. Teams that skip straight to the prompt on launch leave allow rates on the table they never get back.

— Lucas

StorePush: turning lock-screen reach into recovered carts

Using native Apple App Clips, we send lock-screen push notifications to shoppers without requiring signup or app install, putting the ephemeral window strategies covered above into practical use.

We're built for recovering carts within short windows and following up on high-AOV or preorder situations where a missed checkout is expensive. Our guide to App Clip cart recovery walks through the mechanics in more detail. If you're running a Shopify, WooCommerce, BigCommerce, or custom storefront, you can start on our Free plan and move to Pro at $50 per month plus a 5% commission on recovered revenue once you see it working.

FAQ

What is iOS push opt-in and why does it matter?

iOS push opt-in is the process of getting a user's permission to send them notifications, governed by UNUserNotificationCenter.requestAuthorization. It matters because the system prompt only appears once per install, so how and when you ask directly determines whether you can reach that user through push at all.

Can I show the iOS permission prompt more than once?

No. Once a user responds to the system dialog, Apple caches that decision and won't re-show the native prompt on later calls to requestAuthorization. Re-engaging a denied user requires routing them to Settings or using a different channel entirely.

What's the difference between provisional and full authorization?

Provisional authorization delivers notifications quietly to Notification Center without ever showing the system prompt, letting users judge real content before deciding, according to OneSignal's documentation. Full authorization, by contrast, enables banners, sounds, and lock screen alerts after the user explicitly taps "Allow" on the system dialog.

How long does an App Clip's notification permission last?

An App Clip configured with NSAppClipRequestEphemeralUserNotification can request ephemeral notification access that remains active for up to 8 hours after launch. That window is commonly used for time-sensitive flows like checkout follow-ups, since it doesn't require installing the full app.

How does StorePush fit into an iOS push opt-in strategy?

StorePush uses App Clip based lock-screen push to reach shoppers who abandon checkout without ever sharing an email or phone number, filling the gap traditional opt-in flows leave behind. Pricing runs from a Free plan up to Pro at $50 per month plus a 5% commission on revenue recovered through the platform.

Sources