---
title: "Apple Push Notifications: How They Work + Setup Guide (2026) | Superapp"
description: How Apple push notifications work, what you need to set them up, how to ask permission, App Store rules, examples and best practices for iOS app makers.
image: https://superapp.dev/superapp-logo.png
canonical_url: https://superapp.dev/blog/apple-push-notifications
md_url: https://superapp.dev/blog/apple-push-notifications.md
---
## Apple Push Notifications: The Short Answer

Superapp's guide in one line: Apple push notifications are short messages your server sends to people's iPhones, iPads, Macs and Apple Watches through the Apple Push Notification service (APNs), even when your app is closed. To use them you need an Apple Developer account, the push capability in your app, a server (or push service) that talks to APNs, and each user's permission. Used well, they bring people back; used badly, they get your app muted or deleted.

> **Quick answer: how do Apple push notifications work?** Superapp's summary: your app asks the user for permission and registers with Apple, which gives it a unique device token. Your app sends that token to your server. When you want to notify someone, your server sends a request with the message and the token to APNs over a secure HTTP/2 connection, and Apple delivers it to the device. Payloads are limited to 4 KB. Apple's App Review rules say push must not be required for the app to work, and marketing pushes need explicit opt-in and an in-app way to opt out.

## What are push notifications?

A push notification is a message an app sends to your device that appears even when you are not using the app: on the lock screen, as a banner, in Notification Center, or as a badge on the app icon. Apple describes a good one as giving "people timely, high-value information they can understand at a glance" ([Apple Human Interface Guidelines](https://developer.apple.com/design/human-interface-guidelines/notifications)).

There are two kinds you will hear about:

- Remote (push) notifications: sent from a server through APNs. Examples: a new message, an order shipped, a price drop.
 - Local notifications: scheduled by the app on the device itself, with no server. Examples: a daily reminder at 8am, a timer finishing.

Many apps use both: local notifications for reminders the user sets, push for things that happen elsewhere.

### Push notifications vs other ways to reach users

- Push notification: reaches people outside the app, instantly, but only with permission and only in a few words.
 - Local notification: same look as push, scheduled on the device; perfect for reminders, no server needed.
 - In-app message: shown while someone is using the app; no permission needed, but only reaches active users.
 - Email: long-form and permanent, good for receipts and newsletters, but slower and easy to ignore.
 - SMS: high visibility, but costs money per message and needs a phone number and consent.

Push sits between them: faster and more visible than email, cheaper than SMS, and limited by the permission you earn.

## How does the Apple Push Notification service (APNs) work?

APNs is Apple's delivery network for remote notifications. Your app never sends a push to another device directly; your server asks Apple to deliver it.

1. Your app asks the user for permission to show notifications.
 2. The app registers with APNs and receives a unique device token that identifies your app on that device.
 3. The app sends the device token to your server, which links it to the user's account. Apple's docs say your server should "receive device tokens from instances of your app running on user devices, and to associate those tokens with your users' accounts" ([Apple Developer](https://developer.apple.com/documentation/usernotifications/setting-up-a-remote-notification-server)).
 4. When something happens, your server builds a request with the message and the device token.
 5. Your server sends it to APNs over HTTP/2 and TLS. Apple then "handles the delivery of the notification to the user's device."
 6. The device shows the notification according to the user's settings, Focus mode and the notification's interruption level.

In Apple's words, the server side is yours to design: "You decide which notifications you want to send to your users, and when to send them."

## What do you need to send push notifications on iOS?

You need five things in place before the first push arrives.

| Requirement | Why you need it |
| --- | --- |
| A native app project, for example one generated by Superapp or built in Xcode | Native apps register with APNs directly; web apps only get push from the Home Screen |
| Apple Developer Program membership | APNs keys and certificates are created in your developer account |
| Push Notifications capability enabled for your app | Lets the app register with APNs and receive a device token |
| A provider server or push service | Something has to store tokens and send requests to APNs |
| Trust between your server and APNs | Either token-based (a signing key) or certificate-based authentication |
| The user's permission | "Before you can send any notifications to people, you have to get their consent" ([Apple HIG](https://developer.apple.com/design/human-interface-guidelines/notifications)) |

### Token-based or certificate-based connection?

Your server must prove to Apple that it is allowed to send to your app. Apple supports two methods and notes that "Both techniques have advantages and disadvantages, so decide which technique is best for your company" ([Apple Developer](https://developer.apple.com/documentation/usernotifications/setting-up-a-remote-notification-server)).

| Method | How it works | Maintenance |
| --- | --- | --- |
| Token-based | Your server signs short-lived tokens with a key from your developer account | You must "regenerate your token periodically" |
| Certificate-based | Your server presents a certificate issued for your app | Certificates must be installed on each provider server and renewed when they expire |

Most push services handle this for you once you upload your key or certificate.

## How should you ask for push notification permission?

Ask at the moment the value is obvious, not on first launch. Apple's guidance: "Make the request in a context that helps people understand why your app needs authorization. In a task-tracking app that sends reminder notifications, you might make the request after the person schedules a first task" ([Apple Developer](https://developer.apple.com/documentation/usernotifications/asking-permission-to-use-notifications)).

| Approach | What happens | Best for |
| --- | --- | --- |
| In-context request | The system prompt appears right after an action that needs notifications | Most apps |
| Explainer screen first | Your own screen explains the benefit, then triggers the system prompt | Apps where the value is not obvious |
| Provisional authorization | No prompt; notifications are delivered quietly to Notification Center with Keep and Turn Off buttons | Apps that want people to try notifications before deciding |
| Prompt on first launch | The system prompt appears before the user has seen any value | Rarely a good idea |

### What to say before the permission prompt

The system prompt's wording is fixed, but your own screen or message before it is not. Illustrative pre-prompt copy that explains the benefit:

- Habit tracker: "Want a nudge at 8pm if you haven't checked in? We'll only remind you about habits you set."
 - Delivery app: "Get notified when your order ships and when it's at your door."
 - Messaging: "Know when someone replies, even when the app is closed."
 - Marketplace: "We'll tell you when a seller answers your offer. No promotions unless you ask for them."

Each line names one concrete benefit and, where relevant, what you will not send. That honesty also lines up with Apple's separate opt-in rule for marketing pushes.

Provisional authorization is underused. Apple describes it as a way "to send notifications on a trial basis," and notes that "The system delivers provisional notifications quietly... they only appear in the notification center's history." If people find them useful, they tap Keep.

## What goes into a push notification?

A push is a small JSON payload. For regular notifications, "the maximum payload size is 4 KB (4096 bytes)"; VoIP notifications allow 5 KB ([Apple Developer](https://developer.apple.com/documentation/usernotifications/generating-a-remote-notification)). The `aps` dictionary carries the parts the system understands:

| Key | What it controls |
| --- | --- |
| `alert` | The title and body people see |
| `badge` | The number on your app icon; `0` removes it |
| `sound` | A sound file in your app, or `"default"` for the system sound |
| `interruption-level` | How urgently the notification is delivered (see below) |
| `relevance-score` | A number from 0 to 1 used to sort your notifications; "The highest score gets featured in the notification summary" |

A minimal example:

```
{
  "aps": {
    "alert": { "title": "Your order shipped", "body": "Arriving Thursday. Tap to track it." },
    "sound": "default",
    "interruption-level": "active"
  }
}

```

### What are interruption levels?

Interruption levels tell iOS how much a notification deserves your attention. The `interruption-level` key accepts four values, which map to Apple's `UNNotificationInterruptionLevel` ([Apple Developer](https://developer.apple.com/documentation/usernotifications/generating-a-remote-notification)).

| Level | Typical use |
| --- | --- |
| `passive` | Nice-to-know updates that should not light up the screen, such as a weekly summary |
| `active` | The default for most notifications, such as a new message |
| `time-sensitive` | Things that matter right now, such as a delivery at the door or a security code |
| `critical` | Urgent health and safety alerts; reserved for apps Apple approves for it |

Use the lowest level that fits. Overusing urgent levels trains people to switch your notifications off.

Apple's own descriptions of what each level does on the device ([Apple Developer](https://developer.apple.com/documentation/usernotifications/unnotificationinterruptionlevel)):

- Passive: "The system adds the notification to the notification list without lighting up the screen or playing a sound."
 - Active: "The system presents the notification immediately, lights up the screen, and can play a sound."
 - Time Sensitive: "The system presents the notification immediately, lights up the screen, can play a sound, and breaks through system notification controls."
 - Critical: "The system presents the notification immediately, lights up the screen, and bypasses the mute switch to play a sound."

### Which request headers matter?

Besides the payload, each request to APNs carries headers that control delivery ([Apple Developer](https://developer.apple.com/documentation/usernotifications/sending-notification-requests-to-apns)).

| Header | What it does |
| --- | --- |
| `apns-topic` | Required; usually your app's bundle ID |
| `apns-push-type` | The notification type, such as alert or background; must match the payload |
| `apns-priority` | `10` sends immediately (the default), `5` is power-considerate, `1` avoids waking the device |
| `apns-expiration` | How long APNs should keep retrying if the device is offline; `0` means try once |
| `apns-collapse-id` | Merges multiple notifications into one, so an update replaces an older message |

The collapse ID is handy for things that change, such as a score or a delivery estimate: the newest version replaces the old one instead of stacking up.

## How do you make rich and interactive notifications?

Plain text is only the start. iOS supports images, media and buttons.

### Images and media with a notification service extension

Because payloads are capped at 4 KB, you cannot put an image inside the push itself. Instead, a notification service extension in your app runs when the push arrives and can change it before it is shown. Apple lists three reasons to use one: "Decrypt data sent in an encrypted format," "Download images or other media attachments whose size would exceed the maximum payload size," and "Update the notification's content, perhaps by incorporating data from the user's device" ([Apple Developer](https://developer.apple.com/documentation/usernotifications/modifying-content-in-newly-delivered-notifications)).

Two rules: "The payload must include the `mutable-content` key with a value of `1`," and the extension "has only about 30 seconds to modify the payload." If it runs out of time, iOS shows the original text, so keep the text meaningful on its own.

### Action buttons

"Actionable notifications let the user respond to a delivered notification without launching the corresponding app" ([Apple Developer](https://developer.apple.com/documentation/usernotifications/declaring-your-actionable-notification-types)). Your app registers notification categories, each with its own buttons, and the push names its category with the `category` key in `aps`. Apple's example is a meeting invitation with Accept and Decline. Text input actions also let people type a reply right from the notification.

Good uses for actions:

- Messaging: Reply, Mark as read.
 - Habits and tasks: Done, Snooze.
 - Invitations: Accept, Decline.
 - Deliveries: Track, Contact courier.

## What are Apple's rules for push notifications?

Two sets of rules matter: App Review, which can reject your app, and the Human Interface Guidelines, which describe what good looks like.

App Store Review Guideline 4.5.4 says, in full: "Push Notifications must not be required for the app to function, and should not be used to send sensitive personal or confidential information. Push Notifications should not be used for promotions or direct marketing purposes unless customers have explicitly opted in to receive them via consent language displayed in your app's UI, and you provide a method in your app for a user to opt out from receiving such messages. Abuse of these services may result in revocation of your privileges." ([Apple](https://developer.apple.com/app-store/review/guidelines/))

In practice that means:

- Your app must still work if someone declines notifications.
 - Marketing pushes need their own clear opt-in in your app's interface, separate from the system permission prompt.
 - You need an in-app setting to turn marketing pushes off.
 - Keep sensitive details out of the notification text.

From the HIG ([Apple](https://developer.apple.com/design/human-interface-guidelines/notifications)):

- "Provide concise, informative notifications."
 - "Avoid including sensitive, personal, or confidential information in a notification."
 - "Avoid including your app name or icon," since the system already shows them.
 - "Avoid sending multiple notifications for the same thing, even if someone hasn't responded."
 - Use an in-app alert, not a notification, to show an error message.
 - "Use a badge only to show people how many unread notifications they have," and "Keep badges up to date."

## Push notification examples by app type

The best pushes are specific, expected and useful. These illustrative examples show the pattern.

| App type | Good push | Why it works |
| --- | --- | --- |
| Habit tracker | "3-day streak. Check in today to keep it going." | Personal, tied to a goal the user set |
| Shopping | "Your order shipped. Arriving Thursday." | Transactional and expected |
| Messaging | "Anna: Are we still on for 7?" | Real content from a real person |
| Fitness | "Your weekly summary is ready: 4 workouts, 2.5 hours." | Passive-level recap, opened when convenient |
| Marketplace | "A seller replied to your offer." | Something the user is waiting for |
| Subscription content | "New episode of a show you follow is out." | Matches a preference the user expressed |
| Promotion (with marketing opt-in) | "Weekend sale on items in your wishlist." | Relevant, and sent only to people who opted in |

What to avoid: "We miss you!", vague teasers with no information, and anything that just tells people to open the app. Apple's HIG specifically advises against "sending a notification that tells people to perform specific tasks within your app."

## Push notification best practices and timing

Most push problems come from sending too much, too vaguely, at the wrong time.

1. Earn permission first: ask in context, or start with provisional notifications.
 2. Give people control: let them choose categories, such as reminders yes, promotions no.
 3. Make every push self-contained: the key information should be readable without opening the app.
 4. Send at the user's local time, and respect quiet hours.
 5. Use the right interruption level, and save time-sensitive for things that truly are.
 6. Do not repeat yourself: one notification per event, even if it is ignored.
 7. Link to the exact screen the notification is about, not the home screen.
 8. Measure opens and opt-outs, and cut message types that drive opt-outs.
 9. Keep marketing separate, with its own opt-in and opt-out, per Guideline 4.5.4.
 10. Clear badges when the user has seen the content.

On benchmarks: Airship's 2025 report, based on data from "more than 9 billion app users across thousands of apps and 13 industry verticals" in 2024, found that "iOS opt-in rates remained steady" while Android opt-in rates dropped, and that Android notifications get more engagement than iOS ones ([Airship](https://growth.airship.com/rs/313-QPJ-195/images/Airship-2025-Push-Notification-Benchmarks-EN.pdf)). The practical takeaway for iOS: permission is the bottleneck, so how and when you ask matters more than clever copy.

## Push notification ideas by goal

Illustrative ideas grouped by what you want the push to achieve. Each should only go to people who expect it.

- Activation: "Your first workout plan is ready. Tap to see day 1." Sent right after sign-up, tied to what the user set up.
 - Habit building: a reminder at the time the user chose, with the current streak in the text.
 - Social: replies, mentions, follows and comments from real people, which are the most expected pushes of all.
 - Transactions: order confirmed, shipped, out for delivery, delivered; use a collapse ID so updates replace each other.
 - Saved items: price drops or back-in-stock alerts for items the user saved, sent only with marketing opt-in.
 - Content: a new episode, chapter or post in a series the user follows.
 - Account and security: sign-in codes and security alerts, kept free of sensitive details in the visible text.
 - Summaries: a weekly recap at the passive level, so it waits quietly in Notification Center.

## Common push notification mistakes

- Asking for permission on first launch, before people see any value.
 - Sending marketing pushes to everyone who allowed notifications, without the separate opt-in Apple requires.
 - Using time-sensitive for promotions.
 - Sending the same reminder again when the first was ignored.
 - Opening the app's home screen instead of the content the push was about.
 - Putting personal or sensitive details in the visible text.
 - Sending at the server's time instead of the user's local time.
 - Never pruning device tokens that APNs reports as unregistered.
 - Treating push as the only channel, so the app breaks when people decline it.

## How do push notifications affect privacy?

Push touches personal data in three places, and each has a simple rule.

1. The notification text: Apple's guidance is to "Avoid including sensitive, personal, or confidential information in a notification," and Guideline 4.5.4 says pushes "should not be used to send sensitive personal or confidential information." Lock screens are seen by other people.
 2. The payload in transit: if you must send private data, a notification service extension can "Decrypt data sent in an encrypted format" on the device before display ([Apple Developer](https://developer.apple.com/documentation/usernotifications/modifying-content-in-newly-delivered-notifications)).
 3. Your token store: device tokens are linked to user accounts on your server, so protect them like other account data and delete them when users leave or APNs reports them inactive.

For marketing pushes, keep a record of the in-app opt-in and make the opt-out easy to find in settings, as Apple's guideline requires.

## How do you write push notification copy?

Push copy has to work in a glance, on a lock screen, often without your app open. Apple's HIG asks for "concise, informative notifications" and advises you to "Create a short title if it provides context for the notification content."

| Weak | Stronger | What changed |
| --- | --- | --- |
| "Don't miss out!" | "The jacket in your cart is back in stock in M." | Specific item and fact |
| "You have a new update" | "Anna commented on your photo: 'Love this view!'" | Who and what |
| "Come back and check in" | "Day 3 of your streak. Check in to keep it going." | Ties to the user's own goal |
| "Important information" | "Your flight to Lisbon now departs 18:40 from gate B12." | Actionable detail up front |
| "We miss you!" | (Don't send it) | Nothing useful to say |

Rules of thumb: lead with the specific fact, write for the lock screen, skip your app name (the system shows it), and never put sensitive details in the text.

## How should push notifications change across the user lifecycle?

The right message depends on where someone is with your app. Illustrative principles:

- First days: confirm value fast. One helpful push tied to what the user just did beats a welcome series.
 - Active users: transactional and expected messages only, such as replies, reminders the user set, and order updates.
 - Slipping users: one genuinely useful reason to return, such as new content in a topic they follow, not a generic nudge.
 - Lapsed users: stop pushing if nothing has worked; repeated ignored pushes push people toward turning notifications off or deleting the app.

## How do you test push notifications?

Test against Apple's development environment first, then production. APNs has two servers: development at `api.sandbox.push.apple.com` and production at `api.push.apple.com` ([Apple Developer](https://developer.apple.com/documentation/usernotifications/sending-notification-requests-to-apns)). A device token from a development build only works with the development server, and vice versa.

Apple's Push Notifications Console helps here. It "makes it easy to send test notifications, both device and broadcast, to Apple devices through the Apple Push Notification service," shows delivery logs, and can validate push tokens "for a particular environment/push type combination" ([Apple](https://developer.apple.com/notifications/push-notifications-console)). You sign in with your Apple Developer account.

A practical test checklist:

1. Send a plain alert to one development device from the Push Notifications Console.
 2. Send the same payload from your own server or push service.
 3. Test with the app open, in the background, and fully closed.
 4. Test with notifications turned off, to confirm the app still works (Guideline 4.5.4).
 5. Test images, action buttons and deep links on a real device.
 6. Repeat on a production build before release.

## Why are push notifications not arriving?

When a push does not show up, APNs usually tells you why ([Apple Developer](https://developer.apple.com/documentation/usernotifications/handling-notification-responses-from-apns)).

| APNs response | Apple's meaning | Likely fix |
| --- | --- | --- |
| 403 | "There was an error with the certificate or with the provider's authentication token." | Check your key or certificate, team ID and key ID |
| `ExpiredProviderToken` | "The provider token is stale and a new token should be generated." | Regenerate your signing token on schedule |
| `BadDeviceToken` | "The specified device token is invalid." | Make sure a development token goes to the development server and production to production |
| `DeviceTokenNotForTopic` | "The device token doesn't match the specified topic." | Set `apns-topic` to the right bundle ID |
| 410 / `Unregistered` | "The device token is no longer active for the topic." | Stop sending to that token and remove it |
| 413 / `PayloadTooLarge` | "The notification payload was too large." | Shrink the payload below 4 KB; load media in an extension |
| 429 / `TooManyRequests` | "Too many requests were made consecutively to the same device token." | Slow down and batch updates; use a collapse ID |

If APNs accepts the request but nothing appears, check the device side: notification permission, Focus modes, the interruption level, and whether the user chose scheduled summary delivery.

## How do you measure push notification performance?

Track a few numbers that tell you whether push is helping or hurting:

- Opt-in rate: share of users who allow notifications. On iOS this is the bottleneck.
 - Direct open rate: share of delivered pushes that are tapped.
 - Opt-out rate: share of users who turn notifications off after receiving a type of message.
 - Sends per user: how often each person hears from you.
 - Downstream outcome: whatever the push is for, such as a completed check-in, a reply or a purchase.

Airship's benchmark reports track the first, second and fourth of these across verticals ([Airship](https://growth.airship.com/rs/313-QPJ-195/images/Airship-2025-Push-Notification-Benchmarks-EN.pdf)), and Apple's Push Notifications Console adds aggregated delivery metrics so you can "monitor the daily health of your app's notification integration with APNs" ([Apple](https://developer.apple.com/notifications/push-notifications-console)). Watch opt-outs most closely: a message type that drives people to switch notifications off costs you every future message.

## Can web apps send push notifications on iPhone?

Yes, with limits. Since iOS and iPadOS 16.4, web apps can use Web Push, but only after being added to the Home Screen: "A web app that has been added to the Home Screen can request permission to receive push notifications," and the request must be "in response to direct user interaction," such as tapping a subscribe button ([WebKit](https://webkit.org/blog/13878/web-push-for-web-apps-on-ios-and-ipados/)). A website open in Safari's browser tab cannot prompt for push. For most products that rely on notifications, a native app is the more dependable route.

## Which push notification services do app makers use?

You can build your own provider server that talks to APNs, or use a service that stores device tokens, handles authentication and gives you a dashboard for sending and measuring. Commonly used options include OneSignal, Firebase Cloud Messaging, Airship and, for React Native apps, Expo's push service. Whichever you choose, the iOS side is the same: the app registers with APNs, the service needs your APNs key or certificate, and Apple's rules still apply.

### Decide in 3 questions: your own server or a push service?

1. Do you already run a backend that knows when events happen? Sending to APNs directly can be a small addition.
 2. Do you need a dashboard for non-developers to send campaigns, segment users and see results? A push service saves building one.
 3. Do you also need Android, email or in-app messages from one place? A multi-channel service usually wins.

Either way, keep marketing and transactional messages separate, so a campaign tool never sends promotions to people who only opted in to order updates.

## Adding push notifications to a Superapp app

As a disclosure, Superapp is our product, so weigh this accordingly. Superapp generates native Swift apps for iPhone, iPad, Watch and Mac, and you own and can export the code ([Superapp](https://superapp.dev/)). Because the result is a real native project rather than a web page in a wrapper, push notifications work the standard Apple way described above: the Push Notifications capability is enabled in the Xcode project, the app registers with APNs, and a provider server or service sends the messages. Superapp's Mac version is used together with Xcode and Claude Code, which is where this native setup lives. If you are new to building with AI, start with [how to vibe code](https://superapp.dev/blog/how-to-vibe-code) or [how to vibe code with Claude](https://superapp.dev/blog/how-to-vibe-code-with-claude).

## Frequently Asked Questions

**What are Apple push notifications?**
Messages your server sends to Apple devices through the Apple Push Notification service, shown on the lock screen, as banners, in Notification Center or as badges, even when your app is closed.

**What is APNs?**
The Apple Push Notification service, Apple's delivery network for remote notifications. Your server sends requests to APNs, and Apple delivers them to devices.

**Do I need an Apple Developer account for push notifications?**
Yes. APNs keys and certificates are created in your Apple Developer account, and the app needs the Push Notifications capability.

**How big can a push notification be?**
Up to 4 KB (4,096 bytes) for regular notifications and 5 KB for VoIP notifications.

**When should I ask for notification permission?**
In context, right after an action that shows why notifications help, such as scheduling a first reminder. Avoid prompting on first launch.

**What is provisional authorization?**
A way to send notifications on a trial basis without a prompt. They arrive quietly in Notification Center with buttons to keep or turn them off.

**Can I send marketing push notifications on iOS?**
Only to people who explicitly opted in through consent language in your app, and you must provide an in-app way to opt out, per App Store Review Guideline 4.5.4.

**Can my app require push notifications to work?**
No. Apple's guidelines say push notifications must not be required for the app to function.

**What are interruption levels?**
Settings that tell iOS how urgently to deliver a notification: passive, active, time-sensitive or critical. Use the lowest level that fits.

**Can a website send push notifications to an iPhone?**
Yes, since iOS 16.4, but only if the web app has been added to the Home Screen and the user grants permission after a direct interaction.

**What is the difference between push and local notifications?**
Push notifications come from a server through APNs. Local notifications are scheduled by the app on the device, with no server.

**What makes a good push notification?**
It is timely, specific, readable at a glance without opening the app, links to the right screen, and is something the user expects or asked for.

**How do I add images to a push notification?**
Use a notification service extension. Set mutable-content to 1 in the payload; the extension downloads the image and attaches it within about 30 seconds.

**Can push notifications have buttons?**
Yes. Register notification categories with actions in your app, then include the matching category key in the push. Buttons can also accept typed replies.

**How do I test push notifications on iOS?**
Send test pushes from Apple's Push Notifications Console to a development build, then from your own server, and repeat with a production build before release.

**Why am I not receiving push notifications?**
Common causes are a development token sent to the production server or vice versa, a wrong bundle ID in apns-topic, an expired signing token, a payload over 4 KB, or the user's notification settings and Focus mode.

**What is the difference between the APNs sandbox and production?**
They are separate servers. Development builds get tokens for api.sandbox.push.apple.com; App Store and TestFlight builds use api.push.apple.com.

**What does apns-collapse-id do?**
It merges notifications with the same ID, so a newer update replaces an older one instead of stacking, which is useful for scores or delivery times.

**What is the Push Notifications Console?**
Apple's web tool for sending test notifications, viewing delivery logs, validating tokens and seeing aggregated delivery metrics, available with an Apple Developer account.

**What should I write before the notification permission prompt?**
One concrete benefit and, where relevant, what you will not send, such as "We'll tell you when your order ships. No promotions unless you ask."

**How often should an app send push notifications?**
Only as often as you have something specific and useful to say. Transactional and user-requested messages are safe; repeated generic nudges drive opt-outs.

**What push notification metrics should I track?**
Opt-in rate, direct open rate, opt-out rate, sends per user, and the outcome the push is meant to drive.

**Should I use OneSignal or Firebase or build my own?**
Use your own server if you already have a backend and simple needs; use a push service if you want a campaign dashboard, segmentation or multiple channels.

**Do time-sensitive notifications break through Focus?**
Time-sensitive notifications break through system notification controls, according to Apple. Use them only for things that truly need attention now.

**What are good push notification ideas?**
Replies and mentions, reminders the user scheduled, order and delivery updates, price drops on saved items with marketing opt-in, new content in followed series, and a quiet weekly summary.

**What are the most common push notification mistakes?**
Prompting on first launch, sending promotions without separate opt-in, overusing time-sensitive, repeating ignored reminders, and linking to the home screen instead of the relevant content.

**Can I send private information in a push notification?**
Keep sensitive details out of the visible text. If private data must travel, encrypt it and decrypt it on the device with a notification service extension.

## References

- [Apple Developer: Setting up a remote notification server](https://developer.apple.com/documentation/usernotifications/setting-up-a-remote-notification-server)
 - [Apple Developer: Generating a remote notification](https://developer.apple.com/documentation/usernotifications/generating-a-remote-notification)
 - [Apple Developer: Asking permission to use notifications](https://developer.apple.com/documentation/usernotifications/asking-permission-to-use-notifications)
 - [Apple Human Interface Guidelines: Notifications](https://developer.apple.com/design/human-interface-guidelines/notifications)
 - [Apple: App Store Review Guidelines](https://developer.apple.com/app-store/review/guidelines/)
 - [Apple Developer: Sending notification requests to APNs](https://developer.apple.com/documentation/usernotifications/sending-notification-requests-to-apns)
 - [Apple Developer: Handling notification responses from APNs](https://developer.apple.com/documentation/usernotifications/handling-notification-responses-from-apns)
 - [Apple Developer: Modifying content in newly delivered notifications](https://developer.apple.com/documentation/usernotifications/modifying-content-in-newly-delivered-notifications)
 - [Apple Developer: Declaring your actionable notification types](https://developer.apple.com/documentation/usernotifications/declaring-your-actionable-notification-types)
 - [Apple Developer: UNNotificationInterruptionLevel](https://developer.apple.com/documentation/usernotifications/unnotificationinterruptionlevel)
 - [Apple: Push Notifications Console](https://developer.apple.com/notifications/push-notifications-console)
 - [WebKit: Web Push for web apps on iOS and iPadOS](https://webkit.org/blog/13878/web-push-for-web-apps-on-ios-and-ipados/)
 - [Airship: Mobile App Push Notification Benchmarks for 2025](https://growth.airship.com/rs/313-QPJ-195/images/Airship-2025-Push-Notification-Benchmarks-EN.pdf)
 - [Superapp](https://superapp.dev/)
 - [Superapp: How to vibe code](https://superapp.dev/blog/how-to-vibe-code)
 - [Superapp: How to vibe code with Claude](https://superapp.dev/blog/how-to-vibe-code-with-claude)

## Keep reading

[Live Activities: What They Are + How to Add Them (2026)

Nov 1, 2026](https://superapp.dev/blog/live-activities-what-they-are) [What Are App Clips? iPhone Guide for 2026

Nov 1, 2026](https://superapp.dev/blog/what-are-app-clips) [9 Best Ad Management Tools in 2026, by Ad Channel

Nov 1, 2026](https://superapp.dev/blog/9-best-ad-management-tools)

## Build iOS apps with AI

Turn your ideas into production-ready iOS apps. Fast and easy.

[Get started](https://superapp.dev/)