What's New in Notifications

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 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 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 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 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 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. 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 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. 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. 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. 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, 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 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 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. 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 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 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. 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.

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 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. 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.

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. 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 -- 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? 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.

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.

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, 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.

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 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.

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 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, 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 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. It's exciting.

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. 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.

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. 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]