WWDC2015 Session 720

Transcript

X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
[Applause]
>> MICHELE CAMPEOTTO:
Good afternoon, everyone.
Thank you.
You guys have been
doing some great work
with notifications in the US.
So today, we are going over a
little bit the entire system,
how it works and we will see
some new features we created
for you.
Notifications are
a two-part system.
We have iOS notifications
and APNS.
My name is Michele, and I work
in the iOS Notifications team.
We will start with
iOS notifications.
We will talk about
silent notifications
and user notifications
and what is the difference
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and user notifications
and what is the difference
between these two.
We will see notification
actions and a new feature
that I hope you guys
are really enjoying.
In the second half
of the presentation,
my colleague Gokul will talk
about some important
new features
in Apple Push Notification
Service, that I think are going
to make your work much easier
and save you a lot of time.
So let's start from
silent notifications.
Silent notifications are silent.
They don't show UI to the user.
They don't buzz the phone.
So you don't use them
to notify the user.
You use them to notify
your own app.
They are remote notifications.
So they come from the Internet.
Here's your server,
and your app.
Your server sends a
notification to your app,
and if you send the content
available flag to one,
your app knows that there's
going to be new content
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
your app knows that there's
going to be new content
to be downloaded, so it
will start and download it.
Silent notifications
are enabled by default.
The user does not need
to approve your --
does not give permission
to your app to use them,
and you can just
start using them
without asking the
user for permission.
But silent notifications are
the mechanism behind background
app refresh.
At any point you know
that the user can go
in settings and disable them.
So you can't depend on them
always being available.
You don't know if the
user the turn them off,
and you are not getting
a notification anymore.
This also means that silent
notifications are delivered
with the best effort.
That means that when
the notification arrives
on the user's device, the system
is going to make some choices.
It's going to use different
signals from the device
and from the user behavior,
like power or the time of day
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and from the user behavior,
like power or the time of day
to decide when it is a good time
to deliver the notification
and launch your app.
It may try to save
battery or it may try
to match the user behavior
and make the content available
when the user is more
likely to use it.
Next part is user notifications.
As the name says, the main
difference is that you use these
to notify the user, when you
want to tell the user something,
when you want to notify them
of something that happened
on your server, or from
some other user of your app.
They appear in the user
page that you know, banners,
lockscreen, notification center.
Since these notifications
are for the user
and they can interrupt
what the user is doing,
they can buzz their phone.
We do require permission.
You want to make sure that they
want to receive the notification
and they are aware that they
are going to receive it.
That also means that they can
also be disabled at any point
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
That also means that they can
also be disabled at any point
in time, and the user
can change a setting.
So even if you set up your
notifications to be banners
and badges, maybe the
user disables part of it,
and they just receive the
badge and not the banner.
There are two different
types of user notifications.
The first one is
remote notifications
and the second one is
local notifications.
Let's see remote
notifications first.
They are remote, so they
come from the Internet again,
and that's your server again.
That sends a notification
to the user's device.
Now, you see that at this
point in time, your app is not
in the picture yet because
your app is not running.
Your app is launched only
when the user taps
on the notification.
When the user taps on the
notification, we launch the app,
and you have the opportunity
to handle the notification
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and you have the opportunity
to handle the notification
that you sent at that point.
Now, you can in a user
remote notification,
you can set the same content
available flag that you set
in silent notifications,
and that allows your app
to have some time to
download the content
or update the content that it
wants to be displayed so that
when the user taps
on the notification,
your content is available.
And the user sees what it does.
This is a way to have a silent
notification inside a user
notifications like a summary.
Second, is local notifications.
Local notifications are
scheduled by your own app,
directly on the user's device.
There's no server.
There's no Internet.
As before, your app
schedules the notification.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
The system displays it to the
user, and when the user taps
on the notification, your
app receives a callback
in the app delegate
and at that point,
you can handle the
notifications and you know
that the user tapped
on it and wants
to act on the notification.
I said that you can
schedule from your app.
How do you do that?
You can schedule
the notification
in two different ways.
You can schedule them by time,
so you can have the notification
happen with a delay,
after a certain amount of time,
or you can have the notification
happen at a specific time
in the future, a
specific time and date.
Another way that you can
schedule notifications
is geofences.
You can set notifications to
appear when the user arrives
or leaves a certain
location that you decide.
So this is how notifications
work
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So this is how notifications
work
from the user's point of view.
This was how notifications work.
In iOS 8, we introduced
notification actions.
Notification actions allow you
to make your notifications
more interactive,
so that a user can
interact with your app
without actually launching it
and make them more efficient
because when they receive the
notification, they can act
on it right there
without launching the app
and interrupting
what they were doing.
Actions are grouped
in categories.
You can use different categories
to group different types
of notifications
that you are sending
so that you can have
different actions
in different types
of notifications.
Say you have a photo app that
users use to share photos,
you can have a different
set of actions
when someone posts a photo or
when someone posts a comment.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
when someone posts a photo or
when someone posts a comment.
Now, all of this
that we are talking
until now is also
forwarded to the Apple Watch.
You don't need to do
anything, and everything works
on the watch, if the
user is wearing it
and it's paired with the device.
You get the basic and
default behavior just
by having your notification
set up correctly.
If you want to customize
the look of the notification
or the behavior of
the notifications,
I suggest you take a look at
the WatchKit presentations
that we had earlier in the
week and they have a lot
of useful information.
Now, if you don't
always communicate
with your friends using only
emojis as I've been dooing
in the presentation until now,
we introduced a new feature
in iOS 8 for notifications and
that feature is text reply.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
in iOS 8 for notifications and
that feature is text reply.
When you receive a text message,
you can pull down the banner
and respond to the text
message right there.
So we have heard some
feedback, and it looks
like you also enjoy conversating
with your friends using
words instead of emojis.
In iOS 9, we are introducing
user notification text input
so you can use the same UI
and the same interactive
notifications in your own app.
How does that look?
It looks like this.
You send a notification
from your app.
The user can pull down and
type the text response.
Words instead of emojis.
This is how we look.
Let's see how to do this and
how they work, how they behave.
Text input actions are
just a new type of action.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Text input actions are
just a new type of action.
They -- you create and
you use them the same way
that you use the actions that
they were already used to.
They appear in the same spots
that all the other actions
appear, and as you noticed
from these slides, they work
together with other actions.
You can have more than
one action and one or more
of them can be text
input actions.
This is something that
not even messages can do.
How do you create them?
So we said that they are
just actions, like the one
that we used until iOS 8.
So you create them exactly
as you created the
notification actions.
The only difference is that
you set the behavior to be
at text input behavior, so that
when the device receives
the notification
and there's a new action
with the text input behavior,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and there's a new action
with the text input behavior,
we can display the text field.
So here we created our action.
Then we register it by
creating our category.
In this example,
it's a simple one.
We only have a reply action,
but we can add more actions here
and they will appear
in the banner
or in the alerts
in the lock screen.
Then we create our settings
and we register them
with the application.
This is the point where the
user is going to be prompted
for permission to use
the user notifications.
So if notifications are
an option in your app,
they are not required, maybe
you don't need to register them
when the app launches.
You can register them
when the user says, yes,
I do want to receive
a notification.
There is a button somewhere.
How do you receive these
text input notifications?
There's a new delegate in your
app delegate, a new method
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and it's very similar
to the delegate we used
for the old type of actions.
The only difference is that
now you have a new parameter
that tells you the
response from the user.
This is from the delegate
for the remote notifications
and this is the one for
local notifications.
There's a tiny difference, but
they are two different methods.
How do you handle the data
that you receive from the user?
This is the delegate.
We have the identifier that
was set in the category
when we registered
the notifications.
We have the response info,
and that contains a dictionary
with information sent back
from the notification.
In this case, since it's
a text input action,
it will contain the text
that the user typed.
This is a check that the
identifier is actually the one
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
This is a check that the
identifier is actually the one
for the comment reply action
that I created and then I go
and extract the text
from the dictionary.
There's some conversion
to be done,
but when I have the string, I
can do whatever I need to do.
Like, in this example, I
can append it to my chat app
in the view controller.
All of this is also
supported by the Apple Watch.
It just works.
You create a notification.
You create the actions.
You have the text reply and the
user gets the standard Apple
Watch Quickboard to reply
to the notification.
And same as I said before,
if you want to customize the
way it looks or other behaviors,
you can for example customize
the list of responses
that the user can tap on here.
Again, check the
WatchKit sessions
that we had earlier in the week.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
that we had earlier in the week.
Now, I have one more thing.
Unfortunately it's not
a new iPod classic.
It's not super exciting.
It's iOS 8 compatibility.
It's a small thing, but you
need to pay attention because,
say you have an app
in iOS 8 with actions,
and you already had a reply
action because you have a chat
up and when the user receives
the notification, you want --
if they tap on the reply
button, they can go directly
to the conversation
that they were having.
So you open your app in
the right conversation
and they can start
typing right away.
In this case, you would have
used a foreground action
because that is when
we launch the app,
when the user taps
on the action.
Now, when you do this
in iOS 9, and you want
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Now, when you do this
in iOS 9, and you want
to use a text input action, you
would use a background action,
because you don't want
the app to be launched.
You want the text input right
there and the banner to go away
when the user typed
and sends a response.
You see that you have a problem,
and you need your action
to be registered in
two different ways,
depending on if your app is
running on iOS 8 or iOS 9.
So when you are registering
your actions at the beginning,
the piece of code that
we saw, you need to check
on which version of
iOS you are running.
You can check if the API
is available and decide
to do the two things
in different ways.
So this was text input action.
We saw iOS notifications,
how they work in the system.
We saw silent notifications
that you can use
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
We saw silent notifications
that you can use
to have your app update the
content and be already available
for when the user uses it.
We saw user notifications,
and actions.
We saw the new text
input feature
that I hope you guys
are really going to use.
And how all of this
forwards to the Apple Watch
and how it behaves
on the Apple Watch.
And now, I'm going to leave
the stage to my colleague Gokul
who will tell you about
some important news
about Apple Push
Notification Service.
Thank you.
[Applause]
>> GOKUL THIRUMALAI:
Good afternoon.
My name is Gokul.
I work on the Apple Push
Notification Service or APNS.
And I'm really excited
to be here to tell you
about all the new things we
we're doing here this year
with APNS.
So let's get started.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
We will start with a review of
how APNS works, for those of you
that are new to iOS remote
notifications, or APNS.
And then we'll talk about
the new provider API
that we are really thrilled
to be announcing this year.
The flow of remote notifications
through APNS has these
four familiar components.
The bottom right is your
client app that runs
on the operating system
on the bottom left,
and the top left is APNS and
the top right is your provider
that is responsible for
sending remote notifications.
So the flow starts
with you registering
to receive notifications
with the operating system,
from the client app.
When you do that, the operating
system gets a device token
that is unique to your
client app from APNS,
and that is returned
back to your client app,
and then you register
that with your provider
which is your server,
that is responsible
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
which is your server,
that is responsible
for sending remote
notifications.
Now your provider is
ultimately responsible
for sending remote notifications
and the first step to doing
that is to register your topic
in the Apple developer portal,
and get a certificate
that you can use
to securely talk to APNS.
Once you have the certificate,
you can establish a client
SSL connection to APNS
and send your remote
notifications using the APNS
provider API.
Now, the APNS provided
API is an extremely fast,
very high performance server
API with very low overhead,
and it allows you to
send a large number
of push notifications just
using a single connection.
For even higher throughput,
you can create many
connections to APNS if you want.
After you are done sending
notifications you can leave the
connection up and
you can reuse it.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
connection up and
you can reuse it.
APNS will not tear the
connection down immediately.
That way you don't pay the cost
of establishing a
new connection later.
If there's any errors
encompassing your connection,
APNS will return an error
code and close the connection.
That's a review of the
current API that we have.
What happens if you uninstall
your app from the device,
how do you find out
about these device tokens
that are no longer active?
That's where feedback
service comes in.
Feedback service is the way
you can discover apps --
device tokens that are no longer
active for your application
so you don't waste resources
trying to send notifications
that are ultimately
going to be thrown away.
It starts when you send a device
-- when you send a notification
to a device token
and APNS discovers
that the device token is no
longer active, it will store it
in the APNS feedback service.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
in the APNS feedback service.
Providers can then periodically
pull the APNS feedback service
and discover the device
tokens that are invalid
and clean up the database.
That's a quick summary
of feedback service.
Let's look at what's ahead.
Coming next year are
large device tokens.
Device tokens today
are 32 bytes.
And next year, in 2016, they
may be growing up to 100 bytes.
So if you make any assumptions
about the size of device tokens
in your code, or in your
server APIs, now is a good time
to revisit those assumptions.
Large device tokens
coming in 2016.
So that's a review
of the provider API
and what's ahead next year.
Let's talk about what
we are doing this year.
So we have a brand
new provider API
that we think you
will really love.
This new provider API is built
on four primary features.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
This new provider API is built
on four primary features.
And we think that it will help
you send notifications more
reliably without
compromising speed or efficiency
in your apps, in your providers.
The first feature of the
new provider API is HTTP/2.
The new provider API --
[Applause]
The new provider
API is built on top
of the brand new HTTP/2
industry standard.
HTTP/2 is latest evolution
of the popular HTTP protocol,
and I'm really happy to build a
new provider API on top of that.
Why did we choose HTTP/2
for our new provider API,
and what benefits do you get?
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
There are three primary
things that we think
that HTTP/2 really
brings to the table.
The first thing is that
it's a request response,
just like HTTP.
So every notification that
you send from your provider
to APNS will get a response
back from the server.
And this builds on top of
familiar HTTP semantics
that you are already used
to, like URIs, headers,
response codes, things
you can act on.
And this we think will help you
build more reliable providers
to send push notifications.
So request response.
Second, HTTP/2 is a
multiplex protocol.
This is much like the
current provider protocol
that we have today.
So we're not compromising
on speed.
Multiplexing in HTTP/2 means
that you can send multiple
requests simultaneously
on a single connection
to the server.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
on a single connection
to the server.
So you are not wasting resources
setting up new connections
for every request or
anything like that.
Each multiplexed request
response is called a stream.
We will look at that
a little bit later.
So request response
and multiplexed.
The third thing that HTTP/2 is
great for is that it's binary,
much like our current protocol.
We are not compromising
on efficiency
by adopting the new
HTTP/2 provider API.
With binary, HTTP
frames that are sent
over the wire are not text
like HTTP, but binary,
and you also get to
benefit from things
like header compression
with HPACK.
These three things make
it a really ideal choice
for the new provider API.
In addition to these, there
are also some benefits
like being an industry standard.
You can benefit from libraries
and tooling that's already
out there for HTTP/2.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and tooling that's already
out there for HTTP/2.
Overall, we think this is
going to be really exciting.
Now, the flow of HTTP/2
provider API looks exactly
like the flow you have
today, except the connection,
the protocol between the
provider and APNS is HTTP/2.
So you don't need to modify your
client app, the way it talks
to the operating system or the
way it talks to your provider
in order to benefit
from this new API.
You can adopt the API, and you
will instantly benefit from it.
Let's drill into what
that process looks like.
The first step here is
establishing a connection,
from your provider, to APNS.
When you establish a connection,
it uses the same
client certificates
that you already have today
with the current provider API.
So using that certificate,
you can establish a client
authenticated SSL connection
to APNS, and as soon as the
connection is established,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
to APNS, and as soon as the
connection is established,
HTTP/2 starts by
exchanging settings frames.
Settings frames contain
details like number
of concurrent requests you
can issue over that connection
or the header table
parameter sizes and so forth.
As soon as the settings
frames are exchanged,
as soon as you send the setting
frames from the provider,
you can start sending
your notification data,
your notification requests.
Let's take a look at what a
notification request would
look like.
Each notification
request that you make
to APNS is a post request.
This post request
is made to a URI
that includes the device
token and has a body,
the JSON body that's exactly
like the current provider
API that you use today.
And this JSON payload is
delivered intact to the device.
Now, to take an advantage
of HTTP/2 multiplexing.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Now, to take an advantage
of HTTP/2 multiplexing.
If you have multiple requests,
multiple notifications
that you want to send,
then you can send them all
in the same connection.
That's what a request
looks like.
What about a response
to that request?
The response to a request
in this new provider API,
if everything works
great, no problems.
You get a 200 status okay.
Everything is successful,
continue to send
notifications as you already do.
What if there's a failure?
What if you had a bad device
token, and APNS failed
to process your message?
You get a 400 bad request.
The body -- the response body
for that request
includes the JSON payload
with a reason why
your request failed.
It will say "bad device token"
and the connection will stay up.
You can continue to
send more requests
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
You can continue to
send more requests
over this HTTP connection to the
server, and everything is well.
So that's what a request
response looks like.
Now, I think it will be useful
to go through an example
of what a request response using
this new provider API would look
like on the wire.
If you have not seen an
HTTP/2 request response,
this might look like
a lot of text,
but I will walk you through it.
So here is an example.
Notice that this is
a request in HTTP/2
and there are two
frames in the stream.
The first frame is
a header frame,
and the second frame
is the data frame.
The header frame contains things
like the post as the method
or the URI containing the device
token for your application
that you are sending
this notification to.
The header frame also
contains optional parameters
like expiration, ID, priority,
things of that nature.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
like expiration, ID, priority,
things of that nature.
In the data frame is
the actual JSON payload
that you want delivered
to the device.
In this example, this
is a simple alert
and it says hello, HTTP/2.
That's what a request
locks like.
Let's look at what the
response for this might be.
The response in this case
is everything was great.
You get a 200 okay.
Nothing more to do.
Short and sweet.
If there's a failure, say,
the device token was bad,
here's what the response
might look like.
Again, two frames, a header
frame and a data frame.
Notice that the status
now says 400.
And the body is a JSON
payload that has the reason
for why your request failed.
So in this case it was
a bad device token.
So you can act on that
response, and continue
to process other notifications.
So that's a quick look
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So that's a quick look
at the new HTTP/2 request
response provider API.
That's the first feature
of this new provider API.
The next feature is feedback.
What about feedback?
With the new provider API,
we are introducing
instant feedback.
With instant feedback,
you don't need to talk
to a separate feedback service
to get the device tokens
that are no longer active
for your application.
You get -- you can
instantly learn
about them in the response.
So going back to the
flow of feedback service.
Instead of polling
periodically from APNS feedback
from your provider, you can
now instead get feedback
in the response.
And the HTTP status
code in the response,
in the case of feedback, will be
a status 410, 410 meaning gone,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
in the case of feedback, will be
a status 410, 410 meaning gone,
that the device token
is no longer active
for your application.
In addition to this status code
that the device token
is no longer active,
you also get the time stamp for
the last time that APNS learned
that the device token
was no longer active
for your application.
Let's take a look at an example.
So you sent a notification.
You sent a request.
And it turned out the device
token was no longer active
for your application,
so you can clean it
up so you don't send
notifications to it anymore.
The response might look
something hike this.
Notice there's the status
410 and there's a time stamp.
This is the time stamp
that APNS last confirmed
that the device token
is no longer valid
for your application.
So HTTP/2 provider API
and instant feedback.
The third new feature of this
new provider API is simplified
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
The third new feature of this
new provider API is simplified
certificate handling.
We know you make reach
applications with a lot
of features and through
development and production,
we understand that you have to
create a lot of certificates.
We simplify certificate
handling --
before simplify certificate
handling, here's an example
of certificates would
you have to deal with.
You would have a
certificate for,
let's say your application
topic, perhaps one for VOIP,
one for watch complications,
and if you were working
with development and
production environments,
you might have sets of
certificates for each of these.
With simplified certificate
handling,
you now can use a single
certificate for all
of your pushes for
your application.
[Applause]
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
[Applause]
It's exciting.
[Laughter]
So HTTP/2 provider
API, instant feedback,
and simplified certificate
handling.
Three new features of
the new provider API.
Now, last year, we increased the
push payload size from 256 bytes
to 2 kilobites to
a lot of applause.
This year, we are doubling
this to 4 kilobytes.
[Applause]
The 4 kilobyte limit will apply
to all versions of iOS and OS X.
So it's not exclusive to
iOS 9 or OS X, El Capitan.
It will be part of
the new provider API.
So that's the new provider API.
To review, there's a new request
response, HTTP/2 interface.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
To review, there's a new request
response, HTTP/2 interface.
There's instant feedback
where you can learn
about device tokens that
are no longer active.
Simplified certificate
handling will get you a single
certificate for all
pushes to your topics.
And a new 4 kilobyte payload.
The new provider API
will be available
in APNS development
environments this summer.
And we will be rolling it out
to production later this year.
Once again, the new
provider API can be used
to send notifications to all
versions of iOS and OS X.
You don't need to
create any special logic
for version compatibility.
So that's the new provider API.
For more information
on Michele's section
on iOS notification as
well as APNS, please refer
to the APNS developer
documentation.
The new provider API will be
documented later this year.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
The new provider API will be
documented later this year.
You can also access technical
support and developer forums,
and please direct
general inquiries to Paul,
our core list evangelist.
There are related sessions
you may be interested in,
specifically ones about
ClockKit, Watch connectivity,
and things that Michel
demoed and the networking
with NSURL session has
more details on HTTP/2.
Thank you very much.
Have a great evening.
[Applause]