WWDC16 - New in Notifications

When you see a WWDC session titled Introduction to Notifications, you might think it's silly that after 7 years of using notifications, developers need an introduction to them. However, iOS 10 actually brings us a complete overhaul of notifications APIs and convergence of push and local notifications. They are now just called User Notifications, represented by UNNotification instances and they look and work the same no matter where they come from. All the related functionality has moved from UIKit into UserNotifications framework that also packs a ton of new functionality and is available in iOS, watchOS and tvOS.¹

User Notification Center

UNUserNotificationCenter is a new singleton class that you use to deal with notification settings, categories, permissions, as well as schedule local notification based on various triggers. It can provide you with a list of the app’s notifications that are still displayed in Notification Center and you can clear them programaticaly by identifier or just get rid of them all.

Delegate and in-app notifications

The delegate will be notified of incoming notifications while your app is in the foreground and will let you decide if you want to display system notification UI on top of the app.² Why would you want that if you get the full notification object with all the info that you can just use to update your UI? Well, because maybe your user is not in a view where that info would usually be displayed, so instead of rolling your own in-app notifications UI, you can now just let the system do it for you and benefit from custom actions and other goodies.³

The only other method in this delegate will let you know when user performed one of your custom actions⁴ or one of the new system actions, "dismiss" or "default" (when tapping the notification banner or swiping on it from lock screen).

Local notifications

Available triggers for scheduling local notifications include Calendar, Location (including beacons of course) and Time Interval and they can all be configured to fire once or multiple times. You can even reschedule them or change them in any other way before or after they are delivered. Just create a new UNNotification instance with the same identifier and updated content, schedule it, and it will replace the old one.

Remote notifications

Push notifications still come from your server, but since they are represented by same class as local notifications, there is also Push Trigger that you won't be instantiating yourself, but is just there to differentiate local from remote notifications. And that trick with updating local notifications actually works with remote notifications as well. As long as new notification has same identifier, it will replace the old one.

Speaking of remote notifications, that new-ish HTTP/2 API for APNS that was released last year is getting token-based authentication later this year. Bye-bye dealing with push certificates! See What's New in the Apple Push Notification Service for details about that.

New extension points (iOS only)

Notification Service Extensions lets you manipulate a remote notification before it's delivered. This means that for example an app using end-to-end encryption can now receive notification payload with encrypted content and your extension could decrypt it before it's displayed.

Notification Content Extensions let you provide custom UI for your notifications. Keep in mind that notification body can't be interactive, but you might be able to mimic a single tap/swipe interaction with the "default" action. Advanced Notifications session goes into more detail about those.

And more

You can now also add title⁵, subtitle and attachments to notification content.

One last thing to note is that Local and Remote Notification Programming Guide which is being linked under resources of both sessions isn't updated yet, so don't let that fool you with all the old UIKit notification APIs.