If you use iOS devices on a daily basis, you are probably very familiar with notifications. Sometimes you may have been using your device when you received such a notification; other times, the device might have been in your pocket, on your desk, or somewhere else.
Notifications are a perfect way for apps to inform users about information in an app that might be of interest to them. New messages in a messaging app, breaking news events, or friend requests in social apps are just a few examples of great use cases for notifications. From the get-go, it's important that you're aware of the fact that a lot of apps are fighting for the user's attention at all times. Notifications are a great way to gain the user's attention, but if you send too many notifications, or only use notifications as a marketing tool, instead of as a way to provide meaningful information, it's very likely that the user is going to disable push notifications for your app at some point.
This is especially true since iOS 12. When a user swipes to ignore a notification, the user will be asked if they would like to adjust the notification settings for the app that sent the notification, or even turn off notifications for the app entirely. This new behavior makes it more important than ever to only send meaningful notifications to users.
The following six forms of notifications can be sent to users:
- Sounds
- Vibrations
- Visual notifications (such as banners and alerts)
- Badges
- Critical notifications
- Provisional
Most apps use a combination of these, and you will learn more about them in a real-world scenario soon. A unique type of notification is the critical notification. A critical notification is sent to the user regardless of whether or not the device is in Do Not Disturb mode, and plays sound even if the device is muted. Critical notifications can't be implemented by all applications, as they are reserved for apps that have very good use cases for sending potentially disruptive notifications.
Examples of good use cases are health-related notifications or alarm systems. If you plan to send critical notifications to your users, you must ask Apple for permission, so they can grant your app the appropriate entitlements if they decide that your use case is valid.
Sending provisional notifications is a new feature in iOS 12 that allows your app to send notifications silently to your users, without explicit permission beforehand. Asking your user for permission to send them provisional notifications will automatically grant your app permission to send notifications without ever prompting the user. Instead, the user will silently receive notifications from your app, and they will be able to choose whether they want to continue receiving notifications from your app, or deny the notifications permission altogether.
There are two ways for apps to send notifications to their users: local notifications and push notifications. Local notifications are scheduled by an app and kept on the device. To trigger these notifications, you use either a location, calendar, or time-based trigger.
Push notifications are pushed to a device through a server and the Apple Push Notification Service (APNS). Push notifications are always delivered by APNS using best-effort delivery. This means that a notification will be sent to the user, and if this fails, APNS may or may not try again. There are no guarantees made about this, so you should never assume that your notification did or did not end up on the user's device.
Push notifications can send either a user-facing notification, or a silent notification. A user-facing notification will actively notify the user about what happened, often in the shape of a banner or badge icon. A silent notification signals the app that it should be woken up to perform a background fetch. You have seen this mechanism in action in Chapter 15, Syncing Data with CloudKit.
When a single app has multiple notifications to show to the user, iOS will group them automatically to avoid spamming the user's notification screen with a huge list of notifications from a single app.
The following screenshot shows a sample of grouped notifications:
While this type of grouping might be exactly what your app needs, there are cases where you might want to group notifications in a slightly different way. For instance, if you are building a chat application, you might want to group all messages for a single conversation, but show multiple notifications if a user has notifications for several ongoing conversations, as shown in the following screenshot:
When you schedule or send a notification, you can specify a thread identifier for that notification. If the thread identifier is set for a notification, iOS will group your notifications based on this identifier, rather than grouping all notifications for a single application together.
In order to complement the notifications you send to your user, you can implement notification extensions. These extensions add a whole new dimension to notifications, especially for devices that support 3D-Touch. There are two types of extensions you can add to a notification—service extensions and content extensions.
Service extensions allow you to modify or augment the contents of a notification before it is shown to the user. Content extensions allow you to display a custom notification interface when the user 3D-Touches a notification.
You will learn more about notification grouping and extensions later. Before that, you will learn how to ask the user for permission to send them notifications, and how to schedule and handle notifications.