What’s new in User Notifications

Grouping

Grouping is performed by default.
You can use threads by adding the thread-id or threadIdentifier for your notification.
The thread id is already used for content extension forwarding. It now does grouping on notifications as well.
Notifications without thread id are bundled with the notification group for your app.
If you add a thread id, a new group is made for every thread id.
Users can tweak grouping. Automatic groups by app / thread. By app groups by app, ignoring threads. Or the user can turn off grouping to keep old style notifications.
The latest notification is shown on the top of a group
Session “Using grouped notifications” goes into more details.

Allow you to provide a custom, rich view for your notifications. (not new)
Content extension is coupled to a notification using the notification category.
You can update the view in response to users tapping notification actions.
Notification actions cannot be modified on the fly, so since iOS 12 you can access and modify actions on a notification content extension. You can use extensionContext?.notificationActions to retrieve the current actions. This property is mutable so you can assign new actions on the fly.
This means you can assign actions outside of the category assigned to the notification.
In iOS 12, context extensions can now receive touches from the user. You must enable user interactions in the extension’s plist.
In iOS 11 users can launch the app by tapping on the notification, app icon and through actions.
In iOS 12 you can call perform default action to launch the app. The notification delegate handler is called with the default action if you do that.
To dismiss the context when the user taps something in the content extension, you can call a dismiss content extension method. This does does not remove the notification from the user. You must call a separate method for that (see docs)

Users can now configure their notifications by swiping over a notification and opening the manage view. In a rich notification the top right corner can open the manager. When the user sees a notification that seems irrelevant, iOS will offer options to manage the notifications.
New concept: “Deliver quietly” and “Deliver prominently“. Prominent notifications are the current style. Show in the lock screen, show a banner, play sound etc. Quiet notifications show up in the lock screen but don’t make sound or show banners.
When a user chooses to turn off notifications, they are presented a confirmation dialog where the user is offered to go to a settings view in the corresponding app to do granular notification management. Must be implemented by devs. System settings also links here when the user is in the settings for your app.
userNotificationCenter(_:openSettingsFor:) is called on the user notification center delegate. If opened from a notification, the notification itself is passed along. When tapped in settings, the notification is nil.
Apple suggests to use threads and only send relevant content to make sure users get value from your notifications.
If you have several types of notifications, allow users to manage them.

This is an automatically “trial” for your notifications that you can opt-in to. Your user won’t see a notification permissions prompt and work right away. However, they won’t show a banner / make sound. They only show in the notification view.
All provisional notifications have a prompt attached to them inline where the user can accept or deny notifications permanently.
In requestAuthorization’s options, you should include .provisional to opt-in. It should be provided in addition to the notifications you actually want to send.
Quite cool because you can now proof to users that your content is worthwhile.
Not sure if you can force the prompt manually after a certain time. (not covered)

Some apps send critical alerts, like a blood sugar measurement device. Or a smart alarm at home. You want to see notifications from these devices even if you have do not disturb on, or if you have your ringer set to off.
Since these notifications are disruptive, not everybody can send them. You must apply for these notifications with Apple so you get a special entitlement.
Critical alerts have their own section in settings. Users can explicitly turn on, or off, critical alerts.
Apps will show a prompt to ask permission for sending critical alerts. To do so .critical must be added to the permission options list.
Setting it up for a local notification is is done by setting criticalSound on the content. In the push payload the sound dictionary needs a critical key with 1 as a value in addition to all the other content you send.

{
  "sound": {
    "critical": 1
  }
}