All right. Good morning. Thank you for coming out this morning to learn what's new in WatchKit and watchOS 2. We've got a lot of great stuff to talk about this morning. Of course WatchKit will be the biggest part of the topic, What's New in WatchKit, after all.

WatchKit is now one part of the overall watchOS platform. There's a whole bunch of other frameworks. Many of which you're already familiar with in building your iOS apps, but there's a few new ones that are specific to watchOS that provide features that are unique to Apple Watch. We're going to talk through all of those new things and some of the ones you're already familiar with to cover what's new in those specifically in watchOS.

That's going to be watchOS 2. First let's talk a little bit about architecture. So you're already familiar with watchOS apps for watchOS 1. The way that works was you had a user interface on both your iPhone and Apple Watch. So you have an iPhone app, and inside of your iPhone app is an Apple Watch that's packaged as part of that Apple Watch app. The UI, your storyboards, your resources, those exist on Apple Watch and are installed there, but your app extension runs on iPhone. The big change with watchOS 2 is that that app extension moves over and runs natively on Apple Watch itself.

This gives you a few really great benefits for your users, the first of course is that now that the user interface and the back-end code is running on the same device you can provide much lower interaction latencies making your apps far more responsive for your users. Of course this also enables some really great new things like running your app when the iPhone is not present.

In order to make sure that that can happen efficiently you need to take some time and figure out how to move your application logic into the app extension. If in watchOS 1 you were spending a bunch of time using open parent application to run code in your iPhone app you want to try and refactor that logic and move it in the extension yourself.

The more code you can get in the app extension the more standalone functionality you can provide when the iPhone is not present. Of course the other big part about stand-alone functionality is that Apple Watch can access the network using tether-less Wi-Fi so your applications can get data off of HTTP servers on the internet even when the iPhone is not present.

If you're used to using NSURL Session in your iOS apps, you already know how to take advantage of this. We'll talk more about that later. But first let's talk about what's new in the WatchKit framework itself. In addition to the big change of moving the code to run natively on Apple Watch, we've also added a whole bunch of new stuff into WatchKit to help you build even cooler apps with watchOS 2.

To give you an idea of some of those things, we've got a list here of some of what we're going to cover right now, we have the digital crown support, layout and animations. A bunch of great stuff, so we'll go through all of these now. First off let's talk about the Digital Crown, this is the really unique interaction mechanisms specific to Apple Watch and you can access this using a simple new control that you can put into your storyboards called wk interface picker.

The picker control is a control that lets you scroll through a list of elements using the digital crown and choose one. It has three different styles. We'll talk through each of those. The first is the list style that you can see here. If you're familiar with configuring complications on the watch face you already know what this looks like. It is a list of items and it can have the optional focus outline around it and a caption up at the top that can give you more detail about the selected item in case it is not obvious from the item itself exactly what it means.

You can choose to hide or show either of those user interface elements. If you have multiple pickers onscreen at the same time you probably want to show the focus outline to make it clear to the user when they turn the crown what's going to end up happening. The second style is the stack style.

The stack style provides you with a list of images that your user can scroll through and pick one. It has this really nice transition automation up while the other fades back. Any content that you might want to allow them to choose from that you can represent graphically you can use the stack style for. It looks really nice.

The third style is the image sequence. The image sequence style lets you scroll through a list of images but without any transitions between them. If you have something that looks really natural as you just move from one frame to the next, you can use this one and you'll get a nice way to pick which image you want to be able to use. You can also see here in the top right corner that we have a scroll indicator in this one. That's an optional user interface element to put on any of the three different styles.

You would want to use this in cases where it is not obvious from the content exactly where the user is in the list of content or how many things there are. For example, if you're letting the user choose from a day -- from an hour out of the day, you probably don't need the scroll indicator because the users likely know how many hours there are in a day and they can figure out where they are in the list. If you're doing something else where it's not self-evident how many things there are, like choosing from emoji, you might want to show the indicator so that they have some context of where they are and how many options they have.

Now, in addition to these three styles, there is actually another great feature of picker control that gives you even more flexibility in how this works in your user interfaces. That's called coordinated images. The really cool thing about this, you can take an animated image that you may have set on some other interface element, like the background of a group, or some wk interface image and you can set it to be coordinated with the picker control itself. This way as the user scrubs through we'll adjust the frame offset in the animated image to match the relative offset in the items in the list. That will let you build user interfaces that look something like this.

As the user goes through, picks which minute, you have a coordinated image in the back that's filling a ring. The combination of the different styles lets you get some really interesting, unique interfaces all controlled by the Digital Crown. Next up, let's talk about animations and layout. So as you know, you build your user interfaces for watchOS in storyboards in Xcode.

In Xcode you have a whole bunch of different options you can set on the different interface elements in your storyboard. Now, in watchOS 1 there were a lot of these that you could change programmatically but some could only be set within the storyboard itself. In watchOS 2 we have gone through and enhanced this to add setters for all of the items that were previously only settable in Xcode at design time. This lets you change a lot of stuff in the program at runtime that previously had to be static.

In addition we have added a new animation API called animate with duration that lets you pass in a block that can include changes that you may have set to your interface elements. Anything that you change within that block will get animated. If you're familiar with UI kits animation API you'll be right at home with this one. It lets you build a lot of cool, smoother interfaces with animation.

Now, there is so much to talk about with that that there is an entire session covering layout and animation techniques for WatchKit, so you should definitely go check that out. There is a lot of things that may not be self-evident and cool tricks and tips to use these APIs to get some really cool effects. So if you come check that out there will be a lot of great stuff to see.

Next up, let's talk about Taptic Engine, this is another really unique element on Apple Watch that lets you get information to your users without actually having to have them read it off the screen. It is really great. The cool thing about Taptic Engine is your users will come to know the feeling and sound of individual haptics and what those things mean in the context of applications.

We have a great API that is simple that lets you just play haptics on wk interface device, you just call play haptic, and there's a list of different styles you can choose from. Each of these as I mentioned has a particular intended use and your users will come to know what they mean because the intent is to deliver information without them having to read anything.

You want to make sure that you use these consistently and they're named in such a way to help you figure out how they should be used. There is also really clear documentation in the docs about the intended use of each and they're covered in more depth in the designing Apple Watch session. So definitely check those things out if you're going to use haptics in your app and make sure you use them consistently so that your users will understand what's happening without having to look at the screen.

There is also a few other pieces of hardware we wanted to enable access to with WatchKit. The first is the microphone. So we've got a new API in watchOS 2 that lets you bring up this recording sheet, record any audio that's going on, play it back before the user acts on it, and then ultimately act by tapping the button in the top right.

So the button in the top right can be named based on whatever is appropriate for your application's context. In this case I call it "send" because I'm assuming I might send a message. But you might also have it be "save" if you were doing something like a voice memo app. It's really simple. It records to a file and when the user hits the confirmation button you'll be handed the file back to act on it as whatever way is appropriate for your application.

Of course, in addition to the microphone, we also want to enable access to the speaker. We have done that in a way that lets you play back audio and video content in your applications. There is three APIs that enable this in different ways. The first one is a new interface object called wk interface movie.

This element lets you get a really standard appearance for what it would look like in your app to see a video file and start its playback. In this case you see I have two onscreen. You provide a poster image, a URL where your content is located, and WatchKit handles playback for you.

That URL can be a local file if you've already gotten the content onto the watch or it can be a remote HTTP URL if it is not already local. If you provide a remote resource, WatchKit will handle downloading it, showing progress and then ultimately playing once the resource was downloaded. If it's local, playback will start really quickly.

When the user taps on the play button they're going to be presented with a great full-screen view of that video and it's going to play back taking up the whole screen with playback controls that fade out right away to give access to quick view into the full content.

Additionally, if you want to start playback some way other than the standard interface element there is also an API that lets you just present that controller directly from some other interaction. These APIs play video and audio content and they're best for playing back short content. The watch is designed for short interaction.

So the best kind of content to play here is something that's not going to be very long. You probably don't want to be playing a two-hour movie on Apple Watch this way. Sometimes there are some types of audio content that are longer that you do want to play back.

If you're writing something like a podcasting application, you might want to download some podcasts and then go for a run, listen to them on your Bluetooth headphones. We've got another API that is really great for playing back this long-form audio. If you're familiar with the AV foundation APIs you know how to use these. They're very, very similar.

The one difference between this and the AV foundation APIs that you might know from iOS is that in order to enable really high performance and great battery usage for the app it doesn't require that your application continue to run in the background in order to play back that audio.

The file can be handed off to the system to be played back even when your application is suspended and not running. If the user goes to the watch face while out for a run, they can bring up the now playing glance and control the playback of the audio that's from your application even while your application is not running.

So there is a few other APIs that are not related to hardware things that I still want to go over quickly here. The first one here is alerts. Again, I mentioned Apple Watch is really designed for short interactions, so you probably want to be really careful about not over using this API because it does introduce an additional step into some other work flow in your app. There are some times when you just need to ask the user a question to get an answer before you proceed. For those cases, we have the alert API which gives you a consistent appearance for this style of UI.

You provide a title, a description, then the list of buttons and the actions that should be taken in a block. They'll just be displayed and you get called back when the user taps on one of them. In this case I have included a destructive style button making it clear that something destructive will happen when I tap delete here.

We have a great open system URL API which enable a whole bunch of new things. Open system URL can take another URL and sends the user to the messages application to send an iMessage to some recipient that you've defined in your app and even cooler, you can pass tel URLs you can have from your application a phone call started on Apple Watch. When that happens, the in-call UI will show up over your app, the user can make the phone call, as soon as they hang up, they'll be right back where they left the app when they started the call.

We also have integration with Passbook -- PassKit. In fact, the PassKit framework is part of the watchOS so you can get access to the passes that your application may have on iPhone. The pass library is synchronized between iPhone and watch so you get both. Even better, WatchKit now has an API that lets you add passes to the pass library, you hand your PK pass over to the WatchKit API, it presents this way, the user can scroll through it to check out what is in that pass and all the way at the bottom is an add button to add it to the library.

When they tap that, it will be added to the library on Apple Watch, but also on iPhone and all their other devices that are synchronized through iCloud. So it's a really great way to get an end to end pass story all on Apple Watch, from ingestion all the way through to using the pass later.

So that's what's new in WatchKit, there is a whole bunch of stuff there. As I mentioned, WatchKit is just one part of the overall watchOS STK and there are other frameworks, some are new and some that existed and have some new functionality. I would like to talk through a few of the other ones now.

Starting with two that are specific just to watchOS. The first is Clock Kit. So Clock Kit is a framework giving up access to building complications that show up right on the watch face. It is a great way to get your data in front of the users really, really quickly.

There is a few styles of complications, and Clock Kit supports all of them. And to give you an idea of what that is let's look through the watch faces, see what they are. Here we have our utility face and there are three different complications visible on this face right now.

You see complications with different sizes and shapes and Clock Kit supports formatting the data in the appropriate way to display in each of these complications. If we look at our color face for example, this has more square sized complications and they're taller to display two lines of text or an image.

Finally, on the digital modular face we have our biggest complication right in the center and four others are on the edge. Clock Kit provides some great APIs to let you format your data in various different templates to fit all of these different appearances and tailoring it to show the right amount of data given each particular complication size.

Now the other important thing about complications, is that they're right on your watch face which means every time the user raises their wrist and looks at the watch, they want to see the most up to date data right away. If we had to every time the user raises the wrist ask the code to give the current value to be shown, we would already have failed. It needs to be there immediately before the user even raises their wrist.

In order to facilitate that, you provide your app's data to Clock Kit in the form of a timeline. In this case, I've got the data for the WWDC app in the form of a complication and timeline here. If this were 10:00 a.m., the morning of the keynote it might be showing that the keynote is the current session coming up.

As the day progresses, let's say it becomes 2:00 and it already has the data so Clock Kit chooses to show the appropriate thing for that time of day. It would have moved to the platform state of the union. Moving on to 4:00, Apple Design Awards. The great thing with this format, you get the automatic behavior throughout the day without the code having to run all the time, but you also get to participate in time travel without any additional effort on your part.

If the user turned the digital crown to move backwards and see what was happening earlier in the day, clock kit would just switch to showing the appropriate piece of your data for that point in time. Really, really easy to add support for complications and a really powerful way to get your data in front of your users. That's Clock Kit. There is a whole session that goes into a lot of this in a ton of detail and tells you all about the APIs, different templates, everything you need to get started. Check out Creating Complications with Clock Kit.

The next thing I want to talk about, networking. Networking is an important story now that you have code running on both Apple Watch and iPhone. There is two kinds of networking you may wanted to do in your applications. The first of those is you may want to talk to the broader internet.

The way you can do that when you're in either a stand alone mode or when your watch and phone are in the same place, using the NSURL session APIs. These will get to the internet in the most efficient way possible given how your user is currently using the phone including detect over Wi-Fi with tether-less Wi-Fi when the phone is not present.

There is a whole session to talk about NSURL session. Networking with NSURL session so go check that one out. Any server anywhere on the internet, hit, download the data, it is the same API you're used to using if you used it on iOS and it has all the same set of features including background downloads.

Of course, there are some times where you have code now running on both Apple Watch and iPhone and you want to have them share data or talk to each other. We have provided a brand-new framework for watchOS and iOS called watch connectivity that allows you to do just that. Your iPhone can link watch connectivity while running on your iPhone and your watch app can link watch connectivity running on your watch.

So a good example of when you may want to use something like this is when you're downloading data off the internet, such as if you were building a weather app downloading the current weather information. Let's say your user picks up their iPhone and launches the app, you go to the internet, grab the latest weather, you show it to them on their iPhone. If you didn't do anything else, you built the watch app to do the same thing, the next time they looked at the app on the watch, it goes out to the internet, download the latest data and show it there.

But that's not the best we could do, we could definitely do better. We had the data, we just got it on the iPhone and it's in the user's pocket now. It would be really great if we could find some way to take advantage of the fact that we already downloaded our data on one of our devices and not have to do it multiple times.

To facilitate that, that might look something like this. The user downloads the data on their iPhone, you move it over, keep it available on the watch so if the user then goes and looks at the app on their watch the data is already there and it can be displayed without having to be downloaded again.

Of course you may still go out and download the more recent updated version. If you knew, for example, that the weather data is only updating data once an hour, you might have the newest data and not have to do that. You may have something newer available for display right away.

Watch connectivity provides this functionality. There are two APIs that it provides for background downloading, the first is called application context and what it does, it lets you hand over a dictionary of data that you want to have available in your app on the other side whenever it runs next. It's always got the latest version of the data so you just set whatever is current and the next time your application runs, it will be available over there.

Behind the scenes, watch connectivity will transfer the data at the time that's most power and performance efficient. There is also a file transfer API, if you have larger data, more bits of data you can transfer files from your iPhone to your watch and vice versa. Again, it will do it in the background in the times that are most power and performance efficient.

There are also times when you need interactive messaging between the two sides. If your watch app is going to kick off some operation on your iPhone, you may want to send a message over. In this example I've got a go button on my watch. When I tap it, I want to send a message to the iPhone and what will happen is if your app is not already running on the iPhone it will get launched in the background and the message will be delivered so you could do something like start a session or perform some activity on the iPhone. Now I mentioned that these APIs exist on both sides and they are bi-directional, application context can go both ways, the file transfer APIs can transfer files both ways. One difference is in the send message API.

When sending a message from the watch to the iPhone, it can wake your application in the background on the iPhone to perform some activity. However when going the other way from iPhone to watch it won't wake up the watch in the background. Your app has to be running on the watch in order to receive messages coming in from the iPhone.

There is a ton of detail to be had on all of these APIs and there is a whole session about it called Introducing Watch Connectivity, so you should definitely check that out to learn how to move your back end from a situation where it ran on one device into having your code running on both iPhone and Apple Watch.

So those are the three new frameworks that are brand-new and specific to watchOS. There is a bunch much frameworks that exist on iOS that you're used to using in the apps today that have some new functionality or some enhanced functionality specific to Apple Watch. I would like to go over a few of those right now. The first is Core Motion.

Now, Core Motion, as you know, is the API giving you access to the motion sensors in the iOS devices. It also exists on watchOS and gives you access to the accelerometer. As on iOS, on watchOS Core Motion can give you live data while the application is running, but new and cool and specific to Apple Watch is it also records motion data on your applications behalf even when your application is not running at a lower refresh rate and then give that accelerometer data to you in a batch the next time your application runs. Cool way to get insight into the motion when the app is not running.

There is a whole talk about this, What's New in Core Motion, so you should definitely go check that out. Additionally, core location is part of the watch iOS and there is a great way to find out the user's new location, there is a great thing making it super easy to figure out the current location with just a simple API call.

Now, the other thing to note about core location on watchOS is that watch is location authorization is shared between your iOS app running on the iPhone and the watchOS app running on the Apple Watch. As you know, when you go to use core location you have to request location authorization from the user before the app is allowed to find out location. That's true in Apple Watch as well.

Once you have -- once the user accepted the authorization on the iPhone or watch, it applies to both so they won't have to answer the question twice and there is one way to manage that authorization for the users. There is a whole session on core location what's new in core location, a lot of new stuff to learn on that.

Next up is HealthKit. HealthKit is also part of watchOS, same framework with the same set of APIs you're used to using on iOS. The great thing about using HealthKit on watchOS is so much of the health data recorded is being recorded on the watch itself that you now have even more up-to-date live access to the data as it is coming in on the watch itself. You're now running on the same device that's generating that data.

So for example you have really up-to-date heart rate information as it is being recorded and stored in HealthKit. The other great thing about HealthKit and watchOS is it provides API that lets you start workout sessions. These workout sessions can do a lot of the same kinds of things that the workout app on watch itself can do. For example, if you go start a run, you want to record the user's heart rate at a higher frequency, you can use the HealthKit API to start that session and request the heart rate information to be recorded in high frequency.

The other great thing about using this API for your workout applications is it allows the application to continue to come back to the foreground every time that the user raises a wrist in that session. If you're writing a biking app and the user starts the biking session, every time they raise the wrist while in that session they'll see the app and be able to get the most up to date data to find out how they're doing during the workout.

Now, while the user has dropped the wrist and the screen is off, the application is suspended but HealthKit behind the scenes will record all of that data for you so when the user raises the wrist and you get a chance to run again, you update on the data recorded while your app was suspended. This provides a really great way to gather all this data in the most power and performance efficient way possible and provide great experience to your users.

So there is also a whole session on What's New in HealthKit, definitely check that out if you're writing work out style apps or anything that may take advantage of the HealthKit data. I also want to take time and talk about the security framework, which maybe is not the most exciting way to spend time. Trust me, there is important stuff here. If you've used the security framework on iOS you know that this provides you with access to the Keychain.

The Keychain on Apple Watch is really interesting because the unique thing about Apple Watch is that while it stays on your user's wrist it remains unlocked and as soon as the user removes their watch the device immediately locks. You can take advantage of this by storing your credentials and secured data in the Keychain. By doing that, you ensure that as long as the watch remains on the user's wrist you have access to the data and as soon as it is removed the data becomes inaccessible because the watch is locked [applause].

Thanks. He was very excited about that [laughter]! All right. That's security. Next up is MapKit. There is a subset of the MapKit API available as part of the watchOS STK and in particular the MK Map API. The cool thing about this, from your application you hand a location over to the maps app to send the user to go view it in the full maps application.

Not only can they view it, you can start directions and routing from the app. If you have a location and want to have the user be able to start getting directions right to it, you use the MapKit API to begin the directions on the Apple Watch and the iPhone and send the user over to get the directions from the app.

There is also a session in MapKit, What's New in MapKit to learn all about that. The last two frameworks I want to talk about, they're all about getting access to your data on Apple Watch -- your user's data on Apple Watch for types of data that we've already synchronized over.

The first one is the contacts framework. Contacts is a brand-new framework in iOS 9 and watchOS 2 giving you access to the address book on Apple Watch and it has been synchronized because we use it in our own applications and you have access to the local data without having to transfer it. There is a session on the brand new framework, Introducing Contacts Framework for iOS and OS 10, so you should definitely check that out if you're going to be using contact information.

Just like with core location, the authorization to access the user's address book is shared between the iOS app and the watchOS app. Since the user authorized you to get access to the address book on either sides you have authorization on both and there is one place to manage authorization on both Apple Watch and iPhone.

The final is EventKit. EventKit is how you get access to the user's calendar. This has the same set of story as we talked about with contacts. Once you have gotten authorization to access it, it is the same on both your iPhone app and the watch app. So there is a ton of stuff in watchOS 2. Three brand-new frameworks -- well, three watch-specific frameworks, WatchKit, watch connectivity -- oh -- and Clock Kit. Thank you.

Three brand-new frameworks that are specific to watchOS and there is a ton of new functionality available in all of the other frameworks that are specific to watchOS and some are shared across all your apps. There is a lot of stuff when you learn it on one platform you apply it to all of the apps running on all platforms and other frameworks to take advantage of the watch-specific functionality.

There is a ton of sessions throughout the week and other places to learn more stuff. In the documentation we have a transition guide, the WatchKit transition guide having you learn the WatchKit app for watchOS 1 and updated it to run for watchOS 2 to run as a native app on the watch itself.

There is plenty of sample code and the developer forum and the technical support are great places to go to get all your questions answered. That's what's new in WatchKit. Thank you for coming out this morning. I can't wait to see what you guys build with all of this.