Transcript
[ Music ]
[ Applause ]
>> Good afternoon and welcome
everybody to our session, what's
new in user notifications.
I'm Kritarth Jain [inaudible] on
the iOS notifications team, and
we're very excited to be back at
WWDC to share with you all the
new and exciting features around
user notifications that your
applications can start using
with iOS 12.
Today, we will be going over a
range of topics as you can see
from the list here.
We will start with talking about
grouped notifications, a new
paradigm that we've introduced
to iOS notifications when
presented in the user's
notification list.
Then we'll talk about
notification content extensions,
which are existing extension
points with notifications, and
discuss new APIs that you've
added around these.
Then, we'll cover notification
management and talk about all
the new ways in which your
application users can now tweak
your notification settings and
what you need to do to respond
to these new options.
Then, we'll cover provisional
authorization, which allows your
applications to have a trial
phase for sending notifications
to users without their explicit
permission but do it quietly.
And lastly, we'll cover critical
alerts, which allows your
applications to send important
notifications to the users,
which bypass certain system
settings if your users allows
your applications to do so.
So there's a range of topics to
be covered today, and let's
begin with looking at grouped
notifications.
Now up to iOS 11, all new
incoming notifications for the
users were inserted in a
chronological order in the
notification list.
So these would be interspersed
across multiple applications,
and it would be hard for the
user to find a certain
notification or triage multiple
notifications together.
So starting in iOS 12, we've
decided to improve this by
introducing notification
grouping, so now, as you can see
here, all notifications across
different applications get
grouped into their unique
groups.
Let's take a deeper look at how
grouped notifications works.
Now all these notifications will
be automatically grouped, so
there's nothing explicit that
you need to do to start using
notification grouping.
However, if you do want to have
your own custom groups then you
can use the thread identifier,
which is an existing property on
the UN notification content
object.
So some of you might already be
using the thread identifier and
for a local notification.
You can set it on the
UNMutableNotificationContent
object as seen here.
And for a remote notification
payload, you can also include it
as part of your notification
payload.
Now the thread identifier might
be familiar to some of you
already.
We use it today for forwarding
notifications to a notification
content extension that is
presented for your application,
which has the exact same thread
identifier, allowing the content
extension view to update it
based on the new incoming
notification.
Starting in iOS 11, we started
using the thread identifier for
doing grouping of notifications,
if the user had turned on
[inaudible] notification
previous.
So we're just taking this
concept and expanding it for all
notifications in general.
So how does this grouping work?
So when a new notification comes
in to you, the user's device, if
there is no thread identifier
set on this notification, then
this notifications gets grouped
with the application bundle.
We can see that from our sample
application here, that as new
notifications are incoming, they
are getting bundled with the
same group and the group is
getting updated with the latest
content.
And then the user can simply
expand this notification group
to see all the notifications
that are present in that group.
On the other hand, if the
notification does have a thread
identifier set on it, then it
gets grouped with all the other
notifications from that same
application with that exact same
thread ID.
What this also means is that the
same application can then have
multiple different custom
groups, depending upon the
unique thread identifiers that
you're setting on them.
A good example of this is the
messages application, where here
you can see there are two
different threads, and as new
notifications are incoming, they
are going to their own
respective groups.
And then the user can expand a
specific group to see all the
notifications that are part of
that group.
So by using the thread
identifier, messages is able to
do so.
Now, your application users also
have the option of tweaking this
notification grouping setting
from your per application
notification setting's page.
Here, they get three options.
If they choose automatic, then
they get the behavior that we
just described.
However, the user also has the
option of just grouping by
application, where the system
will ignore your thread
identifier and group all
notifications into a single
group.
And if the user wants the same
behavior as it exists in iOS 11
today, then they can simply turn
off grouping for your
applications' notifications.
So do keep this in mind when
you're creating your own custom
groups that they create enough
value for users when they
receive your applications'
notifications.
Now what are the different
components of a notification
group?
The content that we show is for
the latest notification that was
received as part of that group.
And then the user can simply see
all the notifications by tapping
on this group, and we expand all
the notifications' content.
And then the user can interact
with all these notifications
individually as well.
The two buttons at the top give
the users much greater control
like collapsing the stack as
well as clearing all these
notifications together.
Now, notification grouping also
makes triaging of notifications
much better.
For example, in this case, the
user can clear all these
notifications together by simply
swiping to the right and tapping
clear all.
Apart from the content of the
notification group, we also show
a summary text.
Now, this summary text, by
default, shows the count of all
the notifications that are part
of that group.
However, you can also create a
custom summary text so you can
give your users much better
context of what kind of
information is included in that
group.
Now, we will cover this API and
go over much larger use cases of
how you can create your custom
groups in the advanced session
around using group
notifications, which will follow
this session.
So let's do a quick summary of
group notifications as we saw
them today.
Starting in iOS 12, all
application notifications are
going to be grouped
automatically.
You can start using the thread
identifier if you want to create
your own custom groups for your
applications, but the user does
have the option of changing this
grouping setting for your
applications' notifications.
And lastly, you can use the
summary text for customizing the
information you want to provide
the user around the notification
groups that you're creating.
All right, so that was group
notifications.
Now, let's move on to the next
topic and talk about
notification content extensions.
Now, some of you might already
be familiar with these content
extensions that we included with
iOS 10.
Content extensions allow your
applications to present a rich
notification view around the
user's notifications, so you can
have a much more customized and
interactive interface for the
notification that the user is
seeing.
Let's do a quick recap of
setting up these content
extensions.
Xcode gives you a standard
template to add a target for the
content extensions to your
applications and once you set
that up, we create a default
class for the notification view
controller, which implements the
UNNotificationContentExtension
protocol.
Here, the did receive
notification method is important
because this is your entry point
for setting up the view
associated with the content
extension, and you can use the
notification object past here to
get all the information around
that notification to set up your
custom view.
The info.plist file associated
with your content extension
gives you more options.
The important thing here is the
category identifier.
Now, this identifier needs to
match the same category
identifier you're setting on
your notification requests
because that's how the system
knows which content extension to
launch with which notification.
Along with this, you can do some
quick configurations of your
content extension such as
setting the initial content size
ratio, hiding the default
content, as well as overriding
the title of this content
extension.
Now, the primary way in which
your users interact with these
content extensions is through
notification actions, and these
actions are presented right
below the content of the content
extension.
Let's summarize how we can set
up these actions as well.
So doing so is fairly trivial in
code.
For example, here, we have two
actions here for like and
comment, and we create a simple
UNNotificationAction for like
and a text input action for
commenting.
And once we've created these
actions, we create a new
category giving it the same
identifier as the content
extension where we want these
actions to be presented.
And then, we pass it, the two
new actions that we created.
Once we've set up this category,
then we call
setNotificationCategories on the
UNNotificationCenter object
associated with our class,
giving it the new category that
we created.
So by simply doing so, the next
time when the user goes to your
content extension we can see
that these actions are now
available for them to interact
with your notification content.
Now let's take a look at how we
can handle the responses from
these actions.
There are two ways to do that.
Firstly, you can handle this
response in the AppDelegate that
is associated with your
application that implements the
UNUserNotificationCenter
Delegate protocol.
Here, the function
UserNotificationCenter did
receive response, includes the
response object which includes
information about the request,
the notification request from
which the user took this action.
However, the content extension
also allows you to intercept
this action response so that you
can update your view and make a
much more interactive and
dynamic experience for users for
the content extension.
So for our sample here, we enter
the did receive response method
and checked the action
identifier for the like action.
And then we update our UI with
the new label as well as update
our application state.
Finally calling the completion
block we do not dismiss.
If you do want to dismiss your
content extension view here,
then you can simply change the
parameter you're passing to the
completion block to dismiss or
dismiss and forward, where we
will forward this response to
your AppDelegate function as
well.
All right, so now that we set
this up, we can see that when
the user takes the like action,
the content extension content
gets updated right there and
then.
So it's a much more interactive
experience for your user and
they're getting real-time
feedback.
However, if you look at the
current state of the content
extension, we see that there is
some redundant information.
The user has already taken the
like action, so having the
action there doesn't really
serve a purpose anymore.
Now notification actions, in
general, have certain
limitations.
They are not very dynamic and
can't be updated based on the
context of your content
extensions.
Also, these tend to be tied to
the notification categories that
you have to define at the time
of your application setup.
So we wanted to address these
issues and we have introduced a
new API around notification
actions, where now we're
exposing these notification
actions as part of the
NSExtensionContext tied to your
content extension.
What this API allows you to do
is access the currently
presented notification actions
to the user as well as replace
these actions by setting a brand
new array of notification
actions for your content
extension.
So going back to our sample,
what if after the user took the
like action we wanted to replace
it say with the unlike action so
that they can do the reverse of
the action they just took?
So using this new API, let's
take a look of how we can set
this up.
So we go back to our did receive
response method and again
identify the like action and
update our application state.
This time, we also create a new
action for unlike, giving it a
unique identifier as well as a
title.
We can also take a look at the
currently presented actions so
that we can extract the comment
action from there without having
to create it again.
Then we create a new array of
these new actions that we've
created and simply set that on
the notification actions
variable.
So once we've done this and the
user takes the like action, then
the UI will automatically update
to show them the new action, and
then the user can then toggle
between the two actions,
depending upon how you handle
that state in your content
extensions.
Now, this API can be used in
multiple other ways as well.
For example, now you can set
your actions at the time you're
setting up your content
extension view in the did
receive notification method.
What this means is your
notification requests are no
longer tied to the category to
define the actions that you want
to present around these
notifications.
You can also now present a
secondary set of actions by
replacing the currently
presented actions.
For example, if the leading
action was rate, then you can
provide a secondary list of the
different types of ratings that
you want your user to take.
And you can also remove all
these notification actions if
you feel it does not make sense
anymore for your content
extension to present these
actions.
So that's the new API around
notification actions.
And we feel this will really
help you enhance the experience
that your users have around your
content extensions with the
different actions now you can
present to them.
Let's move on and talk about
user interaction with these
content extensions.
Now notification actions were
important up till this point
because till iOS 11 we did not
allow user interaction touches
with your content extension
view.
Now we received a lot of
feedback around this.
And I'm happy to announce that
we're taking away this
restriction with iOS 12.
[ Applause ]
So now your content extensions
have the option of opting in to
receiving user interaction
[inaudible] touches, and setting
this up, it's fairly trivial.
All you have to do is add a new
key value option to your
info.plist file.
And the key that we've added is
the UNNotificationExtensionUser
InteractionEnabled.
So going back to our sample,
what if we want to remove the
like action from a notification
action and make it a UI
interaction touch that's part of
the view itself?
So once we've configured our
info.plist file, we can go back
to our content extension view
and create our own custom button
to handle the like gesture.
We add a target for our own
private method and inside that
function, we update the UI as
well as update our application
state.
So here, it's important that
since you're implementing your
own user interactions that you
are responsible for handling all
these actions, responses, and
callbacks from the users
yourself.
So once we've set this up, now
when the user goes to your
content extension we see the
Like button, part of the UI
itself, and the user can simply
interact with that button right
there and then.
So that's the new functionality
that we've added around content
extensions.
And coupled with notification
actions, along with user
interaction touches, you now
have a much richer set of tools
for creating much more
interactive and dynamic content
extension experiences for your
applications notifications
users.
Now let's talk about launching
your application from the
notification content extension.
So today the user can launch
your application if touches were
not allowed by simply tapping
the content extension view.
They could also do so by tapping
your application icon in the top
left corner.
Or you could create a foreground
action, which then would in turn
launch the application.
But what if you wanted to do
this from your own custom
control?
What if you wanted to launch the
application programmatically?
To enable this, there is a new
API on the NSExtensionContext
called performNotification
DefaultAction, which would allow
you to do this now.
Now, what does the default
action mean?
So, as we said, it launches the
application, but at the same
time, it calls the
UserNotificationCenter did
receive response method in your
application delegate.
Now the UNNotificationResponse
object contains the information
of the notification from which
the user came, so you can update
your application state based on
the notification.
And the identifier that's passed
here is the
UNNotificationDefault
ActionIdentifier.
So going back to our sample,
let's see how we can set this
custom control up.
Now again, we create our own UI
button for the all comments and
then tie it up with our own
private function.
And in that function, we're
simply calling
PerformNotification
DefaultAction.
So by simply doing that, you get
this functionality to call this
method programmatically from
anywhere in your content
extension code.
So that was launching the
application.
What about dismissing the
content extension view?
Again, let's take a look at how
the user can do that today.
They can do that by tapping the
Dismiss Button in the top right
corner, or you can create your
own custom notification action,
which would in turn dismiss the
content extension view.
Which you can set up, as we saw
before, by passing dismiss to
the completion block.
But again, what if we want to
dismiss the view through our own
custom buttons, and we want to
do this programmatically?
Say that when the user taps the
Like button, then the view
dismisses because we feel the
user's done interacting with the
content extension.
To enable this as well, there's
a new API called
dismissNotificationContent
Extension that's on the
NSExtensionContext.
We go back to how we set up our
Like button, and now this time,
we also call the new function
that we added for dismissing the
content extension view.
And once we set this up, now
when the user takes the like
action, the view of the content
extension gets dismissed.
Now one thing to note here.
That calling this method does
not withdraw the notification
that was posted to the user.
If you want to do that then use
the existing API for removing
delivered notifications with
identifiers to get that
functionality.
All right, now let's summarize
all the new APIs that we've
looked at today around the
notification content extensions.
We started with talking about
notification actions where now
you can access these
notification actions as well as
replace them dynamically from
anywhere in your content
extension code.
You can now opt in to having
user interaction based on
touches within your content
extension views.
You can programmatically launch
the application from anywhere in
your content extension code as
well as dismiss the content
extension view, depending upon
where you feel it serves best
your user's experience around
the content extensions.
So that's a varied list of APIs
around content extensions, and
we hope this really helps you
enhance your user's experience
around your content extensions
and then you start using these
APIs.
So that was notification content
extensions.
Now, the next topic today we're
going to look at is notification
management, and to tell you all
about that, let me invite my
colleague Teja to the stage.
Thank you.
[ Applause ]
>> Thank you Kritarth.
Hi everyone.
My name is Teja Kondapalli, and
I'm also an engineer on the iOS
Notifications' Team.
And, of course, I'm here to talk
to you about a couple of the new
APIs that we have.
The first of which is
notification management.
But before I dive into this API,
I want to cover some of the user
facing features to give you some
more context and then we can
deep dive into the API.
As our users get more and more
apps on their phones,
notifications become the primary
way that they interact with
these apps.
But often, they find themselves
in a situation like this.
With far too many notifications.
And it becomes hard to sift
through and find the important
ones.
So perhaps to make this easier,
this user has decided that
notifications from podcasts
don't need to be shown on the
locked screen.
Right now to configure that
they'd have to launch the
settings app, find
notifications, find the podcast
app, and then they can configure
their settings.
We wanted to make this easier.
So, in iOS 12, we're introducing
a new management view where the
users can configure their
notification settings directly
from the notification without
having to launch the settings
app.
There's three really easy ways
to get into this management
view.
The first is what we just saw.
You simply swipe over a
notification, tap manage, and
the management view comes up.
The second is if you can go into
the rich notification, you can
tap in the right corner, and you
can also launch the management
view.
And the third is actually in the
list itself.
Depending on how your users are
interacting with their
notifications, they will
occasionally see suggestions,
like this one, that ask them if
they want to keep receiving
podcast notifications.
And from here, as well, they can
tap manage and bring up the
management view.
Let's take a closer look at the
management view.
And we obviously have options
here where users can configure
their notification settings
directly from this view.
But if they want to go into the
settings app and configure in a
more detailed manner, they have
a quick link to the settings for
this application, the
notification settings.
A And also from this view, they
have some actions they can take
directly, the first of which
says deliver quietly, which is
probably a concept that's new to
all of you.
Some of these management views
will also have an option that
says deliver prominently, so
let's talk about what this
means.
In iOS, we have a lot of
settings that users can
configure, and this is really
great for the power user.
The can customize their settings
to every detail, but for the
regular user, we think that we
can help them out by
categorizing their notification
settings into two big
categories.
Notifications that are delivered
prominently and notifications
that are delivered quietly.
Notifications that are delivered
prominently are what we're used
to.
They show up on the locked
screen.
They show up in notification
center.
They roll down as banners.
They badge the AP icon and they
can play a sound.
Notifications that are delivered
quietly only show up in
notification center and they
don't play a sound.
And from the management view, in
addition to configuring whether
they want their notifications
delivered prominently or
quietly, users also have the
option to turn off their
notifications.
Now, I know that you might worry
that your users are going to
turn off the notifications for
your app, so we've added this
extra confirmation sheet just in
case they do tap turn off.
And from here, they can also
turn off their notifications.
But we've also added an API to
add a second option to this
confirmation sheet, and podcast
has taken advantage of this API,
so it says configure in podcast.
This is a link that will deep
link within the podcast app to a
custom settings view that allows
the user more granular control
about what kind of podcast
notifications they want.
And as your apps send more and
more notifications and various
type of notifications, we think
it's really important to allow
them this granular level of
control over what kind of
notifications are important to
them.
This link can also be accessed
from the systems settings app
from your apps' notification
settings.
And you can see for podcasts
it's right at the bottom.
It says podcast notifications
settings.
Let's see how we do this in
code.
In the class that conforms to
UNUserNotificationCenter
Delegate, we have a new delegate
method.
Open settings for notification,
and as long as you implement
this delegate method, those
links that we talked about from
the management view, or from the
settings app, will automatically
be populated by the system for
you.
So when the user taps on any of
these links, this delegate
method will be called.
And it's really important when
this delegate method is called
that you immediately take your
users into the view where they
can configure their notification
settings within your app.
And if you notice, we have
[inaudible] parameter to this
method, and it is notification.
So depending on where the link
was tapped from, if it was
tapped from one of the
management views, it will have
the value of the notification
that that management view came
from.
If it was tapped from the
settings app, the value of
notification will be nil, and
you can use this information to
show the appropriate
notification settings when this
delegate method is called.
So that's what we have for
notification management.
It's a new way for your users to
configure whether they want
their notifications delivered
prominently or quietly, or turn
them off, or even configure them
at a granular level within your
app.
And to encourage your users to
keep getting your notifications
delivered, we think it's really
important that you make the
content in the notifications
relevant.
We also encourage you to use
thread identifiers to group the
notifications when you think
it's appropriate.
This will help the users
organize their lists better and
will make sure that they're not
overwhelmed by the notifications
from your app.
We also think that as your apps
send various types of
notifications, it's really
important to provide that custom
settings view within that app so
that users have more granular
control about what kind of
notifications are important to
them.
That's what we have for
notification management.
And the next big feature I want
to talk to you about is
provisional authorization.
Right now, when a user installs
your app, before they start
receiving notifications, at some
point they'll have to respond to
a prompt that looks like this,
which is asking them if they
want these notifications.
And the biggest problem with
this is, at this point, the user
doesn't know what kind of
notifications this app is going
to send, so they don't know if
they want them or not.
So, in iOS 12, we're introducing
provisional authorization, and
this is an automatic trial of
the notifications from your app.
This will help your users make a
more informed decision on
whether they want these
notifications or not.
So you can opt into this, and if
you do, your users will not get
that authorization prompt that
we just saw.
Instead, the notifications from
your app will automatically
start getting delivered.
But these notifications will be
delivered quietly, and if we
recall, notifications that are
delivered quietly only show up
in notifications center, and
they don't play a sound.
Notifications that are delivered
with provisional authorization
will have a prompt like this on
the notification itself.
And this will help the users
decide after having received a
few notifications whether they
want to keep getting these
notifications or whether they
want to turn them off.
And this turn off confirmation
sheet will also have the custom
settings link if you have
provided it.
Let's see how you can do this in
code.
In the location where you
regularly request authorization,
in addition to whatever options
you might be requesting, you can
add a dot qualifying option
called .provisional.
And if you include this, you
will automatically start
participating in the trial.
It's really important to note
that the .provisional option is
in addition to whatever other
options you may be providing.
That's because if the users
decide to keep getting your
notifications delivered, we want
to know how you want them
delivered, with badges or sounds
or as alerts.
So that's what provisional
authorization is.
It's an automatic trial of the
notifications from your app to
help your users make a more
informed decision about whether
they want these notifications.
And again, to encourage your
users to keep getting your
notifications delivered, it's
really important to make the
content in your notifications
relevant.
And also, it's really important
to use .provisional as a
qualifier option in addition to
whatever other options you're
requesting.
That's what we have for
provisional authorization.
And the last big feature that I
want to talk to you about are
critical alerts.
Often when I'm in the middle of
a meeting or attending something
important, my phone looks like
this.
And as you can see, I have do
not disturb turned on.
Or at least I have the ringer
switch turned off so that I
don't hear any sounds when I get
notifications.
And usually this is really good,
but I would have missed a really
important notification like this
one.
This is a health-related
notification.
That's from a glucose monitor
that's warning me of low blood
sugar, and this is something I
would want to see immediately.
Scenarios like this made us
realize that we need a new type
of notification, and this is
what we call critical alerts.
Critical alerts are medical- and
health-related notifications.
Or home- and security-related
notifications.
Or public safety notifications.
And the key to a critical alert
is that it requires the user to
take action immediately.
The way that critical alerts
behave is that they bypass both
do not disturb and the ringer
switch, and they will play a
sound.
And they can even play a custom
sound.
But what that means is that
these are very disruptive, and
for that reason we don't think
that all apps should be able to
send critical notifications.
Critical alerts.
So in order to start sending a
critical alert, you will need to
apply for entitlement, and you
can do that on the
developer.apple website.
This is what a critical alert
looks like, and you can see that
it has a unique icon indicating
that it's critical.
And it would have also come in
with a sound.
Critical alerts also have their
own section in notifications
settings.
This means that a user can
choose to allow critical alerts
for a particular application but
choose not to allow any other
type of notification.
And before users start receiving
critical alerts, they will have
to accept a prompt that looks
like this that's asking them
specifically whether they want
to accept critical alerts from a
particular application.
So, of course, in order to start
sending critical alerts, you'll
have to request authorization.
So after you apply for
entitlement and get it, in the
place where you regularly
request authorization, in
addition to whatever other
options you want to request, you
can also request a
.criticalAlert option.
And this will give your users
the prompt.
And let's see how it actually
set up and send a critical
alert.
It actually behaves very
similarly to a regular
notification.
You can see that I just set up a
notification with the title body
and category identifier, but
what distinguishes this as a
critical alert is that it plays
a sound.
So I need to set a critical
alert sound.
And here, you can see that I'm
setting the default critical
alert sound that's provided by
the framework.
I can also set a custom sound.
And I can also set a custom
audio volume level.
And of course, critical alerts
can also be push notifications
so all of this information can
be set in the push payload as
well.
So that's what we have for
critical alerts.
They're a new type of
notification that requires the
users to take action
immediately.
And they're very disruptive, so
you need entitlement to be able
to send them.
So that's all the new exciting
APIs that we have for you today.
I just want to quickly go over
all the things that we covered.
We talked about how you can use
thread identifiers to group your
notifications to help your users
organize their notification
lists better.
We talked about all the great
new APIs around notification
content extensions, which will
help you make your rich
notifications much more
interactive.
We talked about how you can
provide a custom settings view
within your app to allow your
users more granular control over
what kind of notifications they
want to receive.
We also talked about provisional
authorizations, which is an
automatic trial of the
notifications from your app,
which will help you users make a
more informed decision about
whether they want these
notifications or not.
And last, we talked about
critical alerts, which are a new
type of notification that
requires the user to take action
immediately and that are
disruptive.
So we hope you take advantage of
all of these great APIs and make
the notification experience for
your users even better.
You can find all the information
about this session on our
sessions' page at
developer.apple.com.
We're session 710.
We have another session just
following this one in hall three
called using grouped
notification where we'll help
you determine how to best group
notifications for your app.
We have two notifications labs,
one today and one tomorrow,
where you can come and ask the
engineers on our team any
questions that you may have.
And on Friday morning, we have
an interesting session called
designing notifications.
That's going to be hosted by the
designers who helped us come up
with the designs for these, and
they'll be talking about
notification best practices.
Thank you and have a great dot
dot.
[ Applause ]