12 Steps to Mastering iOS Push Notifications

David Beck

Last updated Jul 27, 2020

iOS has a number of features around push notifications, but it can be difficult to know what to use for your specific app. While good documentation exists for each individual feature, trying to get a handle on everything that is available and useful can be overwhelming. Consider each of these features and how they might fit into your app.

Note: This isn’t a technical guide on how to implement each of these features or notifications.

Everything here applies to both remote and local notifications, but in some cases, how you implement them between the two can be quite different.

Alert Title, Subtitle, and Body

Alerts and notifications are often treated as interchangeable terms. Technically speaking, notifications can take many forms: sounds, badges, and attachments to name a few. Alerts are the text form of notifications and can appear on the lock screen, in Notification Center, and if the device is unlocked, at the top of the screen for a few seconds.

Originally, alerts consisted of a single “body” field. However, in the last few years, Apple has added title and subtitle fields. These additions allows you to create a hierarchy of information that makes alerts more digestible. Most users receive many alerts throughout the day. By improving the structure of your alerts, you not only set yourself apart, but also make it easier for the user to quickly understand the information rather than ignore it.

If you offer an Android app, it only displays title and text fields, but no subtitle. Technically speaking, a subText field exists, but its placement is too inconsistent between Android versions to rely on. We recommend mapping your title and subtitle fields in iOS to the title and text fields in Android, respectively.

It is important to note that while the body field can wrap to multiple lines, title and subtitle will get clipped if they exceed a single line of text. The body field not only wraps to multiple lines, but if the user expands the alert by long pressing, he or she sees even more text. This makes it OK to include as much body text as you want.

Also keep in mind that the body field is always required. You can’t push an alert that includes only a title and subtitle. Subtitles without titles are not allowed either. For this reason, it makes sense to categorize alerts in three levels of content:

  • If an alert only needs one level of information, style it as a body-only
  • If an alert requires only two levels of information (probably the most common scenario), style it with title and body only
  • If an alert makes sense with three levels of information, include all three

Something fun you can do with your alerts is to use emojis. For instance, Robinhood, a stock trading app, includes chart emojis (📈📉) for alerts about stocks being up or down for the day. This not only helps alerts stand out more, but also makes it easier for users to know what the alert is about.

How to Design a Push Notification Strategy
Read more


Audio cues also can be used the moment a notification arrives. iOS provides one built-in sound for notifications. To use it, set your sound to “default.” To spice things up, bundle your own custom notification tone with your app. Keep in mind they have to be included in your app bundle when you submit to the App Store. No extra sounds can be downloaded after the fact. If a device is on silent when a notification arrives, it will only vibrate instead of playing a sound.

Create a unique sound for your app that ties into your brand in a subtle way. If your app is a budgeting app, the ring of a cash register might make sense. If you’re providing a Twitter client, use a bird chirp. Even if there isn’t a particular sound that ties in to your brand, it’s still a good idea to incorporate a unique sound, both so the user can identify it without opening his or her device and to give your app a less generic feel.

  • Apple has an excellent WWDC session from 2017, titled Designing Sound, where some great techniques are discussed as well as how to create your own unique notification sounds.


Also called “unread counts,” these appear as the numbers on the app icon on the home screen. They draw users in by visually reminding them something new awaits. Maybe they missed an alert, or in some cases, it makes sense to increase badge count instead of issuing an alert so that the user can explore it at his or her convenience.

Be conservative with your badges. While some users condition themselves not to see the red counters on their screen, others prefer to clear it regularly (🙋🏼‍♂️). If your app constantly adds to its unread count, but the user doesn't care about it, he or she will eventually disable notifications from your app or, more likely, uninstall your app entirely.

Make sure it is easy and obvious to find unread content and how to clear it. If a user opens the app and unread content isn't immediately visible, add breadcrumbs to the content. The system tab bar has built-in support for badges too, so if unread content is a few layers deep, include a badge at every step. Of course, if content is important enough to be included in the main app badge, don't make it hard to find.

Remember that users often can read content on other devices. This is especially true if your app has a companion web app your users might use from a computer. In this case, send a silent push notification to update your badge count.


New in recent years, alerts can include attachments. Most commonly, this is a photo, but audio and video are also supported. These appear as thumbnails next to an alert. When you expand the alert, users will see the full-size photo or be able to play audio or video files.

This is a potent way of ensuring your notifications stand out by allowing users to understand the message much faster. For instance, Amazon includes product photos in its shipping notifications. This is a helpful feature in case you get shipping notifications for things you've completely forgotten you've ordered 😅. The podcasting app Overcast includes podcast artwork in its notifications. And in perhaps the best use of attachments, Apple’s own Messages app shows photos and other attachments from messages.

Custom Content Extensions

Alerts use a default system content view when long pressed or force touched. In this view, more body text is revealed and attachments are shown at full size. Apps can provide an extension with custom content view. You can choose to display the same information in a cleaner layout, or show even more information that isn’t in the original alert. For instance, the weekly Screen Time notification includes graphs, more detailed stats, and top apps.

You have quite a bit of freedom in content extensions. Have extra information downloaded and added to what’s in the the notification payload. Even use background fetch to pre-cache content (more on that in a moment) for your extension.

Deep Linking and Custom Actions

When a user taps on a notification, the app opens. During this action, apps get a callback and an opportunity to respond. Make sure you deep link to the notification’s content. Just like with badges, don’t leave the user wondering where they should go next. If the content is already open, consider refreshing it, since there is likely new data to view.

It’s possible to add additional actions to notifications. Opening the app is considered the default action, but you can include buttons that lead to an action in the background or open the app to a specific place or with a specific action.

For instance, voicemail notifications include actions for “call back,” which opens the Phone app and starts a call. “Delete message” works without opening the app and is great for quickly processing notifications. If the voicemail notification is tapped, the Phone app opens to the voicemail tab and that specific voicemail is played.

One particularly special action is text input. This adds a text field above the keyboard. This allows chat app users to respond to a message directly from the notification.

Notification Threads

By default, iOS groups all notifications for an app into a single thread in Notification Center. This helps users who have lots of notifications keep things organized. However, you also have the option to create additional threads for your notifications. For instance, the Messages app creates a thread for each conversation. Rather than having notifications from two different group chats mixed together, they are grouped by conversation. Users can expand each one to see each notification, or they can clear the entire thread at once if, say, they are in an overly noisy group chat they aren’t interested in.

Hidden Preview Placeholder

iOS provides an extra level of privacy to users by hiding notification details when a device is locked. This feature is optional but on by default for phones with Face ID. By default, hidden alerts will show “X Notifications.” We can make this nicer and add more detail without exposing private information. For instance, a messaging app would show “X Messages.” Other apps might have multiple kinds of notifications and instead show “X Comments” or “X Posts.” Such summaries don’t expose the content of the notification but do tell a user more context.

Updating Alerts

Sometimes a notification is sent, but it becomes stale before a user has a chance to read it. It could be a simple typo fix or the score of a game updating in real time. Notifications in Notification Center can be updated after they’ve been sent by sending it again with the same identifier. The notification won’t be shown again, but it will be silently updated in Notification Center and the lock screen. This ensures your app always feels fresh and up to date.

It’s good practice to include this identifier with every notification, even if you don’t expect it to be updated. There’s no downside, and it protects you from accidental duplicate notifications when there is, say, a bug in your push notification server.

Notifications also can be removed entirely. Most often, this is triggered when the user is already viewing the content before receiving a notification. It also comes in handy when the notification ceases to be relevant. A ride-sharing app, for instance, might remove the notification about the driver arriving once the ride begins. The Focus app reminds users to get back to work after a break, but as soon as a new focus session is started, even from another device, the notification is removed.

Show Notifications When Your App Is Open

By default, if an app is open when a notification arrives, the user is not shown anything. The assumption is that your app will handle the notification itself and decide how to best tell the user that something has happened. You can use your own custom UI for this, but a convenient solution is to have iOS show the normal system alert it would have displayed if the app was closed.

Regardless of your UI choice, only show the notification if the user is not actively looking at the content connected to the notification. For instance, if the user is chatting back and forth with someone in a conversation, new messages should appear in the chat view instead of allowing an alert to pop up. Playing a sound is still a good idea, however, you might consider something more subtle. On the other hand, a notification should be displayed if it’s connected to another conversation that’s not currently open.

Background Fetch

Imagine you get a notification that’s well formatted with relevant content and draws your attention. You decide to open it. The app handles the default action and deep links you directly to that content. However, all you see is a loading spinner. After a few seconds, you finally see the content you were just previewing in the notification.

Wouldn’t it be much better if a user could immediately see the content? Most of the time, that kind of magic is not possible. But with notifications, it’s possible by fetching and caching the content when the notification first arrives. When a user opens the app, either from the notification itself or directly, it can be made available to him or her right away. You might also have the content refreshed at that point to make sure everything is up to date.

Requesting Permission

Before you can do anything with notifications, you need to request permission from the user. Don’t make this request immediately. Users don’t want to be asked for notification permission immediately after downloading an app. They are likely to be evaluating your app and aren’t sure yet if your notifications will provide value. This is critical because iOS only allows this request to be made once. If the user declines, the only way to turn them on is for the user to go into settings and enable it manually. For that reason, you should include a fallback state when notifications have been turned off (either from the permissions prompt or later in settings), including a link and instructions to enable them again.

Fortunately, push notifications and user notifications are separate permissions now. So while you can’t show an alert, play a sound, or add a badge without user consent, you can send silent notifications, which may be useful when your app is open or for fetching content in the background.

Even better, as of iOS 12, you can request what is called “provisional authorization.” In this case, the user won’t be asked for permission. Sounds won’t play, but badges will appear and alerts will show in Notification Center and on the lock screen. If your users interact with those quiet notifications, iOS will ask at that point if they want to continue receiving them and enable full notification permissions. This is an excellent way to ease users into receiving notifications when they are new to your app.

Concluding Note

Most apps don’t use every single notification feature. Some use different features for different kinds of notifications. Evaluate combinations of features to find the best mix and experience for your users.

Written By:

David Beck

David is an iOS and backend developer with over 10 years of experience. When not developing apps, he's often crafting woodworking projects or baking delicious gluten-free bread.