Introducing WatchKit for watchOS 2

WatchKit for watchOS 2 introduces many new capabilities for creating responsive Watch experiences. Beyond a faster architecture, learn about all new support for the Digital Crown, fluid animations, and media playback and recording. Find out how to make use of accelerometer and heart rate data, as well as providing physical feedback via the Taptic Engine.

Resources

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.

Looking for something specific? Enter a topic above and jump straight to the good stuff.