Zero-BS Guide to Winning iOS Push Notifications
Chapter 2: How Do I Nail Push Notifications Right the First Time?
Covered in chapter 2:
best for ChatGPT, Claude, and Gemini
second-best for Gemini and ChatGPT
second-best for Claude
Includes .md / .docx / .pdf
2.1
2.1 Five Push Notification Best Practices to Get It Right the First Time
Here’s your push notification survival kit — based on what actually works in iOS 17+ and across modern mobile apps.

Request permission to display alerts, play sounds, or update the app’s icon with a badge counter. Specify all of the interaction types that your app employs:

  • display alerts
  • add a badge to the app icon
  • play sounds

2.1.1 Use a Push Primer — Always

Before you ask for system permission, show your own custom screen. Explain what value your notifications bring, in plain language. This is called a push primer, and it gives users a reason to care before Apple asks them to decide.

🗣 “Turn on alerts to get notified when your trainer reschedules your workout.”

If they tap “Yes,” trigger the real system prompt. If they tap “Not now,” you save your one shot for later. Airship’s 2025 benchmarks show that a well-timed in-app nudge can coax previously opted-out users back on board, boosting opt-ins by about 14% on average.

  • Don’t use ambiguous copy like Allow — this happens in the system dialog only.

Educate users during onboarding about Focus allow-listing if you believe your time sensitive or active notifications earn the spot.

2.1.2 Only Prompt in Context

Timing is everything. Don’t flash the permission prompt or push primer on the first app launch. Show it after the user takes a meaningful action — like setting up their first reminder or completing a profile. That’s when the ask feels natural, not annoying.

Airship’s 2025 benchmarks found that apps embedding the opt-in ask inside onboarding flows score roughly 40% higher acceptance than the average app in their category.

2.1.3 Try Provisional Notifications First

Want to get sneaky-smart? Use Provisional Notifications. These let you send push messages without showing the system prompt at all.

They land silently in the user’s Notification Center. No buzz, no banner — just value. After users see a few helpful updates, they’re more likely to opt in when you ask for full permission later. Users might long-press a notification and promote it to be prominently delivered, or ultimately turn them off.

Founder tip: If your dev team says, “That’s not possible,” point them to Apple’s official docs. It absolutely is.

Dev Handoff: Ability to post non-interrupting notifications provisionally to the Notification Center.
Dev Handoff - 2: Use provisional authorization to send trial notifications.

The main system-driven “nudge” that exists is that iOS will occasionally show a banner in the Notification Center for apps with provisional auth, saying “Deliver Prominently” to encourage the user to fully allow alerts. But if the user has denied permissions (Turn Off), the only path to re-enable is through Settings (often with guidance from your app’s UI) — just like with regular notifications.

2.1.4 Respect the “Don’t Allow”

If a user denies notification permissions, you can’t re-prompt them. Period. But you can still nudge them with an in-app message or a custom prompt primer (must look different that the prompt primer you used initially, when the user chose Don’t Allow).

Include a button that opens the app’s settings directly in iOS. Don’t leave them guessing.

2.1.5 Deep-Link Every Notification

If a user taps a notification, it better take them exactly where they expect — not just to your app’s home screen.


  • Workout reminder → opens that specific class
  • Promo offer → opens the deal page
  • Crypto alert → jumps to the coin’s chart

Every extra tap is a drop-off point.

Dev Handoff - 1: Allowing apps and websites to link to your content.
Dev Handoff - 2: Asks the delegate to open one or more URLs.

2.1.6 Not Every Push Needs to Convert

Sometimes, the goal is trust, not taps. Delivery updates. Score alerts. “Rain starts in 10 minutes.” These messages offer value without demanding anything in return — and that earns you long-term engagement.


Plus, you’ll want to segment your users so that your push is relevant—more on that in later chapters!
2.2
2.2 How To Recover When Users Disable Your Pushes
😬 So You Fumbled the Push Prompt. Now What? You showed the system prompt too early. The user hit “Don’t Allow.” And now… crickets. You can’t re-trigger the prompt. Welcome to the club — most apps blow their first shot.

Here’s how to recover gracefully and still build a useful notification experience:

2.2.1 Make It Obvious They’re Missing Out

Don’t just pretend everything’s fine. If push is core to your app (and you know it improves the experience), let users know what they’re missing — right where the value would’ve appeared.


Example: 🗣 “You didn’t get a reminder because notifications are off. Want to fix that?”

A banner, card, or subtle message tied to context works wonders. Don’t guilt-trip — just connect the dots. This kind of in-app “reminder of absence” makes users more likely to consider re-enabling alerts on their own terms.

2.2.2 Link Them Straight to App Settings

No one wants to dig through Settings > Notifications > [Your App]. So help them out. Add a button wherever it makes sense — settings screen, onboarding, even a contextual nudge — that opens the right screen.

Label it clearly:

🗣 “Turn Notifications Back On”
🗣 “Stay Updated — Enable Alerts”
🗣 “Fix Missed Updates”

This is the best-case path if they’ve hard-denied your app’s permissions.

2.2.3 Offer In-App Controls First (Even If You Can’t Use Them Yet)

Here’s a trick: let users “opt in” to categories of notifications (like reminders, promos, activity alerts) before they’ve actually given you permission. This has two benefits:

  • It makes them feel in control — avoiding the dreaded “all or nothing” dilemma.
  • If they’ve denied permission, you can explain: “Looks like alerts are off. Want to enable notifications in Settings so these preferences take effect?”

Some SDKs like Braze and OneSignal bake this in, but you can DIY it with a toggle screen and a smart fallback if the system permission is off.

Pro move: track who’s opted in to which categories anyway. If they eventually allow push, you’ll already know what to send.
2.3
2.3 Notification Audit Sprint
Audit what you’re actually sending—garbage in still equals garbage out.

1. Inventory every trigger.
Dump all local & remote events into a sheet (orders shipped, comments liked, 2FA codes, ‘flash sale starts’, etc.).

2. Categorize by intent.
  • Security
  • Transactional
  • Social
  • Informational
  • Marketing
Anything that doesn’t fit is probably noise—kill it.

3. Assign interruption-level ruthlessly.
Time-sensitive? Let the courier-on-doorstep ping now.
Marketing blast? It’s passive—period.

4. Weight with relevanceScore (0.0-1.0).
This is the weight the OS uses inside Scheduled Summary: higher score ➜ higher slot. No second “priority” knob exists.

Guideline:
  • 0.8-1.0 Direct mention (someone replied to you).
  • 0.5-0.7 General social buzz (friend posted).
  • 0.2-0.4 Content drop (new article).
  • 0.0-0.1 Background filler.
Over-inflate these and iOS silently buries your whole app.

5. Thread smartly.
Define a stable thread-identifier for anything sequential (chat, order-status, comment chain) so users see one tidy stack instead of a confetti cannon.

6. Log it, live it.
Keep the audit doc alongside your product spec and update it every time a PM says, “Let’s just add one more notification…”

Pro tip: treat relevanceScore as a scarce currency. Spend it only on pushes that will earn taps; otherwise the OS (and eventually the user) stops trusting you.

Dev Handoff: Sending notification requests to APNs
© 2025 Zero-BS Guide to Winning iOS Push Notifications
written by Konstantin Kalinin
Made on
Tilda