Meet Push Notifications Console

♪ ♪ Artem: Hi, my name is Artem. I’m an engineer on the Apple Push Notifications team. I'm excited to introduce you to Push Notifications Console. It is a brand-new tool which combines a few features that will help you integrate push notifications into your app. I’ll start by sending some notifications from the console, which can be helpful for end to end testing. Next, I’ll use the delivery log feature to analyze some common problems. And finally, I’ll introduce you to some additional tools that you can leverage to work with authentication and device tokens. To begin, I’m going to cover some Push Notifications basics. Push notifications are short messages that are sent to a user's device from an application or website. They are an incredibly powerful tool to expand the capabilities of your app. There are millions of push notifications delivered to Apple devices each second, enriching user experience. These notifications are delivered in real time and are designed to provide users with timely and relevant information. This allows for a more dynamic experience when it comes to updating your application. Push notifications can help to increase user engagement, and allow them to always stay up-to-date with your app. Here’s a brief overview of how it works. The backend that enables the delivery of push notifications is called Apple Push Notification service, or APNs for short. The story of a notification begins when you prompt the user to allow notifications from your app. If the user agrees, a Device Token is generated by APNs and then sent to the device. That token uniquely identifies your app on that particular device.

Usually the token is then forwarded to your application server which stores it for future use. When the server wants to send a push notification, it uses the stored device token to address the notification through APNs.

APNs then delivers the notification to the app on the device with the corresponding token. Note that device tokens can change, so it's essential to keep them up-to-date on the server side for accurate and reliable delivery. The Push Notifications console is a brand-new tool that provides a variety of instruments for interacting with APNs. If you're developing an app and adding push notifications to it, you might want to have a quick way of testing it end-to-end. That’s where the send feature comes in handy. I’m developing the Backyard Birds app. It's now spring, and some birds are returning from their wintering grounds, so I want to let users know about that. I’m going to create a new notification. Give it a name, provide the device token of the app on the phone, and then fill some payload attributes. I’ll use the name of the app for the title.

The subtitle will say “Important Update.” And the body will be the “Robins are back” message.

Now that it's ready, I’m going to click send.

When a device receives a push, it displays a notification.

The history of the notifications sent from this page is preserved for your convenience in the sidebar on the left. I want to reuse the last notification, but slightly change the message. I’m going to copy the message that was just sent and create a new notification.

Here, give it a name.

And then toggle this switch which allows me to enter the payload in raw JSON format.

I’m going to insert the payload I just copied and only change the message to a different one.

Supply the same Device token, and then send it.

And the device receives an updated notification.

The Console allows you to test many types of notifications and different attributes. You can specify the environment...

Try different push types...

Set the exact expiration...

Try different priorities...

And send any type of payload.

Next up, I’ll cover the Delivery Log feature. Sometimes there are situations where a notification you send is not received, leaving you uncertain about what happened to it. Using this tool might help you analyze such cases. As a notification travels through the APNs stack the events that reflect its delivery process are recorded. And now you can retrieve that information, using the new header that APNs returns when the notification is sent. Here’s how it works. The device can emulate a situation where a notification is not received by enabling Low Power mode.

Then, I go to the Send tab and resend one of the notifications.

I’ll give it a name, paste the payload, supply the device token, and set the expiration date sometime into the future.

But this time, after clicking “send” the notification will not show up on the device.

To find out what happened, I’m going to copy the new type of ID that APNs returns in HTTP response, “apns-unique-id”.

After switching to the “Delivery Log” tab, I'm presented with a search field where I can put the ID I just copied. Once I run the search, I can see the history of the notification as it traveled through the APNs stack. Here the last event is "stored for device power considerations," which explains why the message was not delivered. In this case, the phone was in Low Power Mode, so it deferred receiving some notifications to conserve battery.

When Low Power mode is disabled, the notification is received and displayed on the device.

After it's delivered, the corresponding update can also be seen in the delivery log.

With this tool, you can analyze a variety of situations. Each history event not only describes what happened, but also why in corresponding tooltips.

For example, a notification can go to APNs storage if the device is offline or can be discarded if the app was removed from the device. You’ll find more examples when you start working with the tool. This feature is available for notifications sent through regular APNs API as well. You need to record “apns-unique-id” from APNs response to be able to query this information. And for the notifications sent from the Console, there’s no need to switch to the “delivery log” tab, the same information is available on the Send page itself.

As you integrate your app with APNs, you’ll work with different types of tokens used for authentication and sending notifications, and the console also provides a variety of handy tools to help you work with them.

Let’s cover authentication first. There are two types of authentication with APNs: Certificate-based and token-based.

Certificate-based authentication relies on SSL certificates to establish a trusted connection between your server and APNs. You need to create and manage certificates for each app and environment within the Apple Developer portal. Keep in mind that certificates expire and need to be renewed periodically.

Token-based authentication uses JSON Web Tokens for secure and efficient authentication between your provider server and APNs. It requires generating a token signed with a private key associated with your Apple Developer account. Private keys don't expire like certificates. As part of Push Notifications Console, there's now a tool that can generate an authentication token for you. All you need to do is supply a private key, obtained from the developer portal...

And associated key ID. After supplying these pieces, a new token will be generated. You can then use it to authenticate your requests against APNs. Keep in mind that the validity period of these tokens can not exceed one hour, so they need to be rotated periodically. And when you generate a token, your key is not uploaded anywhere. It is only used in your browser, so your private information is preserved. If you already have a token, but think it might not be working, you can leverage another tool, authentication token validator. I’m going to take the token I just generated, and then paste it into the validation tool.

Here, I get back the validation result, which will either confirm that the token is valid, like in this case, or provide you the reason why it’s not. For example, when I supply a token I used a while ago, the validation result is telling me that the “issued at” claim is too old, which effectively means that the token has expired. And lastly, there’s the Device Token validator. As you remember, these tokens are used to specify the recipient when you send a notification. They are tied to a concrete environment and push type. When you enter a token, you will get a response that will tell you which environment and push type the token is valid for, if any. For example, when I supply the token that was used used in the demonstration before, we can see that it is valid for Alert & Background push types and Development environment. Hopefully you’ll enjoy using these features and find it easier to integrate Push Notifications into your app, providing people with new exciting functionality. Get started today. Send push notifications to test integration end-to-end. Examine delivery logs and get better insight into the delivery process. Validate your tokens and generate new ones, all from the console. For more information on implementing push notifications on the client, check out “The Push Notifications primer” video from WWDC20. Thanks for watching. ♪ ♪