Good morning. My name is Jon Lee. I am a manager on the Safari and WebKit team. This is Session 614 and you are here to learn about Implementing OS X Push Notifications for Websites. You know, since iOS 3 and OS X Lion, you've been able to integrate push notifications into your native apps. And boy, do users love them. Apple has sent over 7.4 trillion push notifications to users. So, clearly, users love getting push notifications on their devices.

So why is that? Well, I love push notifications because push notifications gives me the information that I really want to know about and the app tells me that information at the best time it is for me get it which is immediately. I don't have to open up the app every time that I want to see an update.

So, like for example I was doing a dress rehearsal for this session last week and I was having some trouble finding the conference room that I needed to be at, and so I was trying to go through my mail to find those directions to get to the conference room.

And a friend of mine actually texted me, telling me exactly where I needed to go and that was great because I didn't have to be in the messages app in that conversation in order to be able to know where to go and for me to get to my dress rehearsal on time.

Push notifications are fantastic because even if I'm asleep or my phone's on silent, or it's just not a good time for me to attend to my phone, I know that all those notification are going to be grouped to in Notifications Center and that place is super easy to access.

Anywhere on iOS, I can just swipe down on my phone and I will see that push notifications that were most recently posted per app grouped together in Notifications Center. And this is great, not just because I know exactly where to go to get my notifications, but because seeing the collection of those notifications per app kind of gives me-- it tells me a story, it gives me some context about what the app is trying to tell me.

And if one of those notifications are of interest to me, I can just swipe on that notification or tap on it and iOS will take me right back to the app and show me more details about that notification. Finally, I love push notifications because I get to fully control when and how I receive them.

So, like I want to install a new app and I launch it, I don't automatically get subscribed to that app's push notifications, I get asked. And if I accept the invitation to get those push notifications and the app ends up sending me too many of them, I have so many different choices. The app might provide me some granularity over like when I want to receive those push notifications.

I could turn those notifications off completely. If it's just that the time isn't right, I can turn on "do not disturb" or as a last resort I could delete or uninstall the app on my phone. So, those are the reasons that I love push notifications for all of the native apps that you write.

But I bet for many of you, not only do you have amazing native apps, but you also have amazing websites. So, new in Safari 7 on OS X Mavericks, I'm really excited to announce that your website can now send push notifications to your Mac users. This is great because just like push notifications on native apps, your users can fully control when and how they receive their push notifications.

And push notifications are just the thing to put in your website to get users to return to your website. And for those of you with websites that are ad supported, that means real revenue. So, in this morning session, I like to go through the four things. The first is to get some background about notifications. The second is to learn how it works behind the scenes. And third is to see how to implement push notifications for your website. And the fourth is to talk about some best practices. So, let's get started.

One thing you may not already know is that you actually can send notifications to your websites on-- can send notifications to your users on their desktop in Safari 6 on Mountain Lion. They're called "Local Web Notifications" and it's based on the specification by the W3C Web Notification Working Group.

Local Web Notifications and Push Notifications are websites that are actually quite different from like assistance perspective. So when the user goes to your web page, your web page will contain some JavaScript that actually tell Safari to send those notifications to the user's Notification Center. Whereas with push notifications, it's actually your server, which we call a Push Server that send those notifications to a service that Apple controls called Apple Push Notification Service or APNS. And APNS knows how to directly connect to your user's Mac to send that push notification.

But more than just from like assistance perspective, local notifications and push notifications on websites are actually managed very differently for-- on the user's Macs. For example, a web page can only send a notification while the user is open to your website. Whereas with push notifications, they can be send at any time.

The user doesn't have to be on your website. The user doesn't even have to have Safari open. And likewise, if the user exits out of your website or quit Safari, all the local notifications that you posted actually disappear. Whereas with push notifications, it doesn't matter, they're always are right for them for your users to see.

Next, the notifications that get shown on the desktop are a little-- are presented a little bit differently. For local notifications, because it's Safari that's sending those notifications that actually gets the Safari icon, and to give some more detail about like where that notification came from, we kind of put in the subtitle of the notification, your domain name. A contrast that would push notifications which actually use your website icons, so there's no need to have kind of add this extra information, they know exactly where that push notification came from.

Next, local notifications end up all being group underneath the section for Safari, which means that like if the user has a lot of websites open that are using local notifications, they all end up getting kind of shuffled together and your notification might get lost in the mix. Contrast that with push notifications, your website actually gets its own dedicated center in Notification Center. So, you website is actually treated just the same as your apps.

Finally, when you click on a notification, for local notifications, it actually takes the user to the tab that actually sent that notification that makes it front most on the user's desktop. With push notifications, since Safari might not have-- be actually be open, clicking on that notification is exactly like clicking on a link. And so, it just opens it up to your website to a web page that provides more detail about that notification.

All right, so we just talked about the differences between push notification-- local notifications and push notifications for websites. What about the difference between push notifications for your native apps and push notifications for websites? Well, you don't even have to worry about memorizing this table because they're actually the same. We've done everything we can from your point of view as a developer to make push notifications between your native app and your website the exact same thing.

So, just to go through it quickly, for native apps and websites, your push notifications can be delivered at any time, the Apple website does not have to be open. The notification gets labeled with your app or websites' icon. They get grouped together based on their app or website to their own dedicated section and Notification Center, and clicking on them opens up the app or the website to take-- to give them more detail about that notification.

So, my last thing about background, I just kind of wanted to talk about how the operating system, make sure that nobody else is trying to forge anything you do and talking about basically verifying your identity. And the best way to talk about this with respect to push notifications for website is to see how it works in apps.

So, in order for user to have push notifications for your apps, there are two things that you need, right? You need your app that you've submitted to the App Store and then you need your server, your push server that actually sends those push notifications to the user's devices.

So how does Apple know that the app and the server actually both come from you? Well, Apple does this through the use of certificates. With the private key of a certificate that you get from the developer portal, you can create a digital signature that only you can create and that Apple verifies in order to make sure that you are who you say you are.

And when it's time to actually send a push notification to APNS, your push server uses a second certificate but also from the developer portal to that-- to connect to APNS. And when those notifications are sent, APNS knows that-- from that certificate that you-- that the push notifications are coming from you.

So together, Apple knows that it is you that's controlling your user's experience with your app and its push notifications. So now, what about website identity? You don't bundle your website together, right? Like anybody can create a website and you don't submit your website to a Apple Website Store.

So how does Apple know that it is you and that you are authorized to actually send push notifications? Well, what we do is we ask your web server to create an identity that represents your website and we call that a "push package". And it's that push package that you sign using something that we call a website Push Certificate and you create your digital signature and this signature and the push package gets sent to Safari and Safari will actually do that check to make sure that you are authorized to send push notifications. And then when it's time to send those notifications to APNS, you use that exact same certificate to connect to the service. So it's actually easier to implement push notifications on websites because you only have to manage one cert whereas with apps, you have to manage two.

All right, so that's a little about the background. Let's talk about how it works. I'm going to take your through two important things I need to happen. If you understand these two things, you understand the feature. The first is how users subscribe to your website's push notifications. So, once you've adopted the feature, websites that go to your website-- users that go to your website on Safari 7, on Mavericks, will see an invitation to subscribe to your website's push notification. If they accept that invitation, Safari will then contact your server for your service credentials. And you're going to return those credentials in the form of that push package that I talked about earlier. Safari will then validate the data in your push package and verify your identity.

And if that succeeds, then it's going to prompt the user to confirm their subscription. When the user confirms that they want to subscribe, then Safari will send something called a device token to your server and tells your server to register that device token. And this device token is just a string that Apple uses in order to target that users Mac.

By the way, if the user wants to change their and then they want to unsubscribe from your push notifications, they can go Safari preferences and they click a little radio button that says they deny permission, meaning they want to unsubscribe, and then Safari will make that exact same call of the device token except this time it'll tell you to un-register and we expect you to delete that device token from your server.

OK. So that's the first. The second thing was-- is about delivering those push notifications. So, now that your server has the device token and the notification itself called the "Message Payload" we combine them and create what we call notification packet and you're going to deliver that to APNS over a secure protocol using that website push certificate. APNS looks at the device token and knows exactly how to connect to the users Mac and that notification gets displayed in the user's Notification Center.

If the user decides to click on that notification, it's just like clicking on a link, so it takes them to a web page in Safari or the user's default web browser. OK. So we talked about these two things, let's see how they work in action. So I'd like to bring up Brian Weinstein, the engineer on the Safari team.

Thanks Jon. Now, I am Brian Weinstein, an engineer of the Safari team and I'm going to show you what-- how interacting with push notifications will work for your users. So, we've made up a website to show of this feature, bayairlines.com. And I have a flight to Boston later tonight and I would like to be updated about information about my flight.

So, as you can see we have a visual affordance to sign up for push notifications and when you click the Subscribe button, we show-- Safari shows an alert asking me whether or not I would like to subscribe for push notifications. And it is branded with the websites icon and the website's name.

When I choose Allow, you can see that the user interface has automatically updated to give me some preferences for what kind of notifications I would like to listen to. So, let's say I'm at the airport, I'm having some food and I would just like to know when my gate changes so I can find out if I need to head somewhere else. What I can do is I can subscribe for notifications when my boarding gate is changed and then I can just quit Safari. And what's so powerful about these push notifications is that they can be delivered even when Safari isn't running.

And you can see that I was given a gate change and it gives me the new gate. And if I want to find a little more about that notification, I can open up Notification Center, select the Notification and it will launch Safari and give me even more information about my gate change. And some other things that are great about push notifications for websites is that they are first class citizens in the rest of Mavericks UI.

So, if I open the notifications preference pane, you can see that Bay Airlines is listed right alongside all of the other apps with your website icon. And this is where you can change how you can configure how your alerts are delivered either in better form or alert form, and you can also look at-- you can also adjust how many notifications you see in Notification Center.

And if you want to change your notification preferences altogether in terms of unsubscribing or subscribing, you do that through Safari's preferences where every website you signed up for-- I've signed up for push notifications for are listed here and I can either Allow or Deny push notifications through there. And so, that is what push notifications for websites looks like. And now we're going to learn a little bit more about how to implement it. And now, I'd like to hand it back to Jon. [applause]

So we've learned a little bit about how it works behind the scenes, let's figure out how to implement it. There are two things that you need to do. The first is actually to get a certificate from the developer portal. And don't worry, I will take you through every step to get those-- that certificate. And the second thing is you need to add notification support to your server. And what do I mean by that? Well, the server actually kind of serves three different roles and you need to implement support for each of those roles.

The first is you need to ask the user on your website, you need to invite them to subscribe to your push notifications. You need to write a web service back end and then when it's time you need to send them push notifications. But a better way to kind of think about these three tasks is that the first is how your website communicates to your users that you've got this great feature, the second is how Safari communicates with your web server, and the third is how your web server communicates with APNS to deliver those notifications. So first, let's talk about getting that Push certificate.

Getting a push certificate, super simple, it's just two steps. One, you have to Register a put-- website Push ID and the second it to create a certificate based on that push ID. So, in the developer portal, you go to the certificate's identifiers and profiles page and on the left hand side you will see a new item that allows you to register a website push ID, just click on that Plus button in the upper right hand corner and you'll be taken to a form where you need to put in two pieces of information.

Both of these pieces of information are just names. It's just for different audiences. So the first one is just human readable description and this description is just for you. It'll be used throughout the developer portal but Safari won't see it, your users won't see it, your server won't see it.

The second is how your-- how the code actually knows about your website or can identify your website. And we recommend the use a reverse domain string. The developer portal will make sure that it's got that web prefix, and that's it. We just registered the push ID. Now, let's create the certificate.

So, you're going to go into settings and you see these detailed instructions of creating a certificate signing request. And the certificates I knew in quest will create a private key that you will use to sign your push package as well as the certificate itself you'll be creating to connect to APNS.

So, it's going to create a file, you're to upload that file, and you've got your certificate. But the certificate is in a format that actually-- that's actually not what we need in order to actually sign our push package. So for that, install the certificate in a keychain access. Right click on it and you want to export that certificate to a P12 file, and that-- it's that representation of your certificate that you will use in order to sign your push package.

OK. So now we got the certificate. Next, it's time to do the fun stuff. It's time to do some coding. So, the first thing is to invite your users to subscribe to push notifications on your website. So we've created two new JavaScript APIs that you use on your webpage. The first is to see if the user has been asked before already and if not, you use the second API which is to ask them. So, let's take a look at the first one.

You're going to call window.safari. pushNotification.permission and you're going to pass in the website push ID which is that push ID that you used in order to create you website push certificate, right? It's a synchronous call and it's going to return a JavaScript object that has a permission property and that property can have three different values. The first is default which means that the user has never been asked before.

The second is denied, where the user has been asked before but they said they did not want to subscribe. It's when in that modal dialog you said, "don't allow" so the user clicked on Don't Allow, and the third is when they click Allow and they confirmed their subscription and in that case you'll see that the permission has been granted. And if the permission is granted, they'll be a second property which contains the user's device token. And you can use this device token in order to change your website UI to give your users some more granularity over the kinds of push notifications that they receive.

So, in the demo that we just saw, it's like seeing the different kinds of reminders that Brian wanted to get notified of. Now let's say that the user has never been asked before. So the permission will be default, that first one, right? So, next we have to actually request permission.

And for that, you call window.safari.push Notification.requestPermission, it's an asynchronous call and you're going to call-- you're going to pass in four parameters. The first is the URL to your web service, so it's that second-- the second thing that you have to implement. It must be-- it must support HTTPS and this represents the base URL to your web service and I'll get into how to implement that web service later.

The second is the push ID which you've seen before. The third is something that we added for you guys and we're calling it userInfo which should sound familiar for those of you who use Cocoa APIs. It's just simply a way for your website to talk to your web service because you recognize that you might have those two roles implemented on separate hardware.

It's basically just a simple dictionary of strings and you can put anything in there to help you identify the user that's logged in to your website or maybe some preferences that they want in terms of the notifications they receive or even the language in which they want to receive those notifications.

Finally, you're going to pass a callback function that will get invoked when the user has finally made a decision. Like when the modal dropped down, a dialogue appears and they decide one way or the other. We will invoke this callback and pass in that permissions object that you saw for the first JavaScript API. In the case that the user confirms, you're going to see the granted permission and that device token. In the case that they said "no" you're just going to see the denied permission cause you don't need the device token in that case.

All right, so we've asked users on your website to subscribe. Now, it's time to write that web service back end. So, let's review how users subscribe to your push notifications, so bring up that diagram. So any arrow that you see going from Safari to the server represents an endpoint that you're going to have to implement in order-- that you're going to have to implement in your web service.

So the first is when Safari contacts your web service in order to get that push package, when that push package has returned and Safari will do a validation and if anything went wrong during that validation, it will then contact your-- the second endpoint and tell your what went wrong. But if everything succeeds and the user confirms their subscription then it will contact the third endpoint where we register the device token to your web service.

There is a fourth endpoint that's not in this diagram and that's when the user changes her mind and decides to unsubscribe. We make a very similar call except instead of saying where register device token we say un-register this device token. So let's talk about that first line about getting that push package.

You can think of this as being Safari just calling a function, except the function is in the format of an HTTP request. And this function contains two different parameters. The first is the websitePushID and the second is that userInfo from the request permission call but serialized as a query string. .So for many of you that only have one website, you can basically ignore the first one 'cause the websitePushID will always be the same. But the second one, you might want to pay attention to in order to be able to tailor the push package that you return.

So, just to review, here's that requestPermission call, that third parameter, userInfo. Here's an example of what I could-- we could pass in for the Bay Airlines site. We pass in the log in of the user as well as their frequentFlyerID and that will get converted by Safari to this string, it looks like a query string and that will be in the HTTP body in the requester your web service.

So, when this endpoint is called, we expect your server to create that push package and what does that look like? Well, if push package is nothing more than a zipped archive of a whole bunch of files formatted and structured in a specific way. And for those of you who have some familiarity with Passbook, you might recognize that this actually follows the way that passes are constructed. So the first set of files are just the icons representing your website. This will be used throughout the UI and you'll see how they map later.

The second is a file that we call website.json and it's a dictionary with information about your website. Let's drill down a little bit into it. The first two you've seen already. It's the URL to your web service and the second is your websitePushID. The third is your websiteName and this will be used in the UI when we ask the user to confirm their subscription or in Notification Center.

The fourth is what we called allowedDomains and it's just a list of domains that are allowed to request permission from your users to subscribe to your website's push notifications. So why would we add something like this here? Well, it's to prevent somebody trying to spoof your website from being able to get those device tokens and sent push notifications on your behalf. So, one way that a spoofer could try to pretend to be you is to take this push package that you would normally serve and serve that to users instead.

But what will happen is during the verification algorithm, Safari will take a look at the domain that was making the request for the permission and compare that against this list. And so, in the case of the spoofing website, that website won't be here so therefore Safari won't-- Safari will fail and you'll be notified of that. So really, this-- having this list here is a way for you to protect yourself against people who are going to try to-- or going to try to forge your notifications.

Next is what we call an authenticationToken and it's similar in its purpose to userInfo. Remember that with userInfo, we were saying it's just a way for your website to talk to your web service. This is a way for your web service to talk back to itself because the web service, we don't expect to maintain any sort of state. So, when the user changes their mind about their subscription to push notifications, you need a way to identify that user and so you can use this authenticationToken to do that.

Finally, we include urlFormatString and the reason why we included this here is because, like I said, like when you click on that notification it's like clicking on a link. Well, so the notification is going to have that URL. But for many websites, that URL is really long and because notifications payloads can only have a limited size, those URLs might actually take up all the space available, and so you won't have any room for your notifications. So, we have this here as a way for you to be able to reduce the amount of space that your URL needs in the notification and you'll see that it's formatted very similar to strings in Cocoa.

OK. So we just talked about the things that kind of describe your website. The next two pieces are how Safari can validate your identify. So the first thing is a manifest.json, it's a dictionary of all of the files we just talked about that contains references to all the files that we just talked about and the SHA1 checksums.

And this is kind of what that looks like. As you see it, the keys are all relative passed to those files and then the values are the checksums and I've truncated them here for readability. So why would we do something like this? Well, if a spoofer try to change your icon or change the name of your website, when Safari does its validation algorithm, it's going to find that the checksums for those files are not going to match what you have here, right? So that's how we-- that's the reason why we have this file.

And then finally, you're going to sign that manifest using the private key of your website push certificate. And we do this because when the push package gets sent to Safari, it will check the signature against the manifest and if they don't match, that means that some other developers try to sign it with an invalid certificate.

OK. So now, that's the push package, you zip that up and you send that back to Safari. Safari will then validate kind of checking all the things that I talked about. And if anything went wrong like a file is malformed or there is a typo in the website.json, we will then contact a logging endpoint and that's the second endpoint to report what went wrong. And super simple, it's what-- this is what it looks like, and you'll notice that the body is just formatted like a JSON object that contains list of the human readable strengths explaining like what exactly went wrong.

But hopefully, you have a major push package correctly and so we prompt and confirm. And at this point, that we can actually see how elements in the push package map to the UI. So just briefly, here's that dialogue that Brian saw when he clicked on that Subscribed Button and you'll see that the icon comes from the icons in the push package and the websiteName and the website.json map into the text asking the user to subscribe.

OK. So now, the user says I want your-- I want Bay Airlines push notifications so now it's time for Safari to send that device token over to your web service. And this is what that call looks like. There are three pieces of information. The first is the deviceToken itself and that's what you're going to want to store in your databases.

The second is the websitePushID which again for those of you with just one website, you can just ignore that. And the third is the authenticationToken that you put in that push package and that's how your web server, your web service knows who to associate the device token with.

If the user changes their mind because they don't want to subscribe to your push notifications anymore, we actually make a request to the exact same endpoint except instead we use the HTTP Delete Method so just look for the method and you'll know whether to add that device token to your databases or remove it.

And that's it. That's all you need to do in order to implement your web service. Now, it's time to send those push notifications. So those of you who had experienced implementing push notifications for Native Apps, we'll be happy to learn that it works exactly the same way for websites.

For those of you who are not familiar, this is the format that you send to APNS. It looks like it's JSON formatted, and in that notification you include the elements that will be in the notification so that includes the title and the body. And for those users who decide to see your notifications as alerts instead of banners, then this action value will override the title in the Action button in the notification.

And instead of having custom data which you can do with Native App Push Notifications, we-- or you have the URL and that URL can provide all the context that you need in order to get-- in order to take your users to the right detail. So, here we've decided to express it in terms of URL args and the reason for that is because we don't want you to necessarily include the entire URL 'cause it might be too long and you have a limited size in your notification payload.

In fact, that payload is limited to 256 bytes. So be sure to take advantage of that URL format string in the push package. And when you send that notification, make sure that you always send it to the APNS's Production Environment. There is no support for pushing your notifications to the Sandbox.

So now that we got the payload and we have the push package from earlier, we know now how to construct everything. So, in the notification itself, the icons come from your push package and the title and body come from the payload. And for users who are seeing your notification as an alert will see your Action button title override that button.

The notification in Notification Center will appear as such. The header gets its icon and website name from your push package and the actual notification itself comes from the payload. And when the user clicks on that notification, we combine the URL format string from your push package and the URL args from your payload, combine them together to make the final URL that takes the user to see more details. So, I'd like to bring Brian back up to show you how these all works behind the scenes.

Thanks, Jon. So now we are going to look at what happens when I use-- when I sign up for push notifications from the website's point of view-- from the web server's point of view. So as you can see, we have a terminal window open with some-- with the web service log output from bayairlines.com and we also-- as a little bonus, we'll get to see what happens if you happened to make a mistake in generating your push package.

So when I want to sign up for push notifications, I will click the Subscribe button and some-- and there is an issue with the web server's push package. As you can see, Safari sends a request to V1 push packages and then the website identifier and we-- and then the web server will log some user info and send back a push package.

But as we can see, the push package Safari did not validate the push package correctly and there was a-- and we send an issue back to V1 log saying, "Refer URL bayairlines.com is not in the list of allowed domains". So, as Jon described from earlier in the talk, allowed domains are-- is in the website.json file so let's open that up and see what's in there.

And as you can see, we have allowed domains it's just listed as bayairline.com. So, we very-- we just have a simple typo, we just need to add an S to make it bayairlines.com, save it, and what the Bay Airlines web server will do is when you-- when we try and sign up for push notifications, the server will automatically generate a push package based on the files that are-- based on the files on the file system. So, we don't need to generate a new push package, it will be done automatically. We can just reload the web page and try again.

And that time it works correctly and we were given-- we were told that we were asked for permission to sign up for notifications. We click Allow and you can-- and then when we-- when the user finished signing up for push notifications, we sent the device token to the Bay Airlines web server and in the HTTP Authorize Header we have the userInfo specified in the push package. Now, let's open up System Preferences again because I want to change my type of alert and I want to make it an alert instead of a banner.

So now, let's say there's Wi-Fi on the plane and I want to be updated with the weather for when I land. So when I get notified of weather, I want to be notified of weather conditions on the day of flight. And as you can see, our web server connected to APNS using the Production Environment and deliver this message payload giving me some more information about the weather and it shows up in Notification Center right over here with-- and then we can either just close the notification or see more.

Now, if the user decides to unsubscribe from push notifications like Bay Airlines lost their baggage and they're never going to fly them again, they can open up Safari's Preferences and switch over from Allow to Deny. And as you can see, we sent a delete request-- Safari sent a delete request to the web server saying to-- telling the web server to unsubscribe this device token and not to send any more push notifications to this device token.

And if they happen to have a great deal and you decide to fly them again, you can just click Allow and we will send back that same-- we will send back your device token via that same-- we will send it to the web server via that same endpoint. So that is what your web server will see when users sign up for Push Notifications or unsubscribe from them. Now, let's hand it back to Jon. [applause]

So, you now know how to implement and let's talk a little bit about best practices. So when it comes to your notifications, think about what notifications can be most useful to your users. So all of you that like raise your hands, you know what it's like to get annoying notifications. Make sure that everything that you're doing to send notifications to users informs them.

Remember that the push notification service is the best effort which means we're going to do our best to deliver them but there's not necessary guaranteed that they'll be delivered. So think of these push notifications as an additional rather than a primary means of communicating. Next, remember to take advantage of that URL format string. Here is an example of what we could have done where the URL format string in the push package was something very generic and we put the entire URL inside the notification payload.

Well, all that-- you know, there's a pretty long URL and so it's taking up space that we could be using to actually have in the notification. So, taking out what's common among all of your URLs and putting that inside the URL format string means that you save some space.

In this case, well, remember to strip the white space base from JSON payload. So like in that slide before with the notification payload that I showed you, just taking out that white space saved like 40 bytes or something like that which is like half a sentence, right? So, remember to do that.

Next to our best practices for your web server, remember that when users decide to unsubscribe and we give-- and we touched that unsubscribe endpoint, just remove those tokens from your web service. We don't want you to be wasting your precious resources delivering push notifications that will never get displayed.

Remember to take advantage of the userInfo in the JavaScript as well as the authenticationToken in push package in order for you to be able to identify the user that wants to register for your push notifications. And finally, the best practices for your website. So, think about the kind of service that you want to provide your users.

If your website is the kind that just broadcast a common notification to all the users, then all you need really is a like a file or just a single database table nothing but device tokens. But if you want to provide an experience where users can really tailor the way that they use push notifications on your website, you're going to want to communicate the User Log in on your website and associate that with the device token.

Remember that this is a feature on Safari 7 on Mavericks so you want to check for API ability as an example of what that looks like. And remember to ask users to subscribe at the right time. You don't know necessarily how users have landed on your website and it's probably your-- and probably they're not going to want to be asked immediately.

We recommend providing some kind of switch that allows user to like physically turn the-- physically turn on push notifications on your website. And in the Bay Airlines demo, we did that through a Subscribe button. And finally, think about giving your users some granularity. It gives them the opportunity to really tailor their experience with your website. In the Bay Airlines site, there's multiple types of notifications that Brian could have subscribed to.

So for more information, you can contact Jon Geleynse and Paul Marcos, our evangelists online. There is the Local and Push Notifications for Developers page which contains links to lot of different references that give you more details about notifications in general. And for those of you which should be all of you that have access to the preview of the developer publications, there is a guide called Notifications Programming Guide for Websites that gives much more detail about how to implement push notifications for your website. And of course, there's always the Safari Developer for all of us.

So, push notifications for websites is just one of many awesome new features in Safari. I recommend listening to Tuesday's video on What's New in Safari WebKit for Web Developers. And as I mentioned before that, push package is very similar to the way that passes are made and I would recommend you listening to Wednesday's talk on Integrating Passbook into Your Ecosystem. It's a really interesting to talk about how Apple Online Store adopted passbook and they have some interesting uses for that authenticationToken. So just in summary, I'm really please to announce that Safari 7 on Mavericks now allows your website to send push notifications to your users.

And we've done everything we can to make push notifications for your website and those for your apps the exact same thing. Safari knows that it is you that is that wants to send push notifications to your users because we asked your server to create something we called a push package that signed using a website push certificate. I love push notifications because they tell me the information that I want to know at the best time it is for me to know them and I'm really excited to see how you integrate push notifications into your website.

Not only this is going to be great because your Mac users will be able to take advantage of this great feature when they visit your website, but I really believe you're going to see increased traffic when people return to your website as a result of using these push notifications. All right, thanks for listening. Enjoy the rest of the WWDC and I'll see you at the lab.