Transcript
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
[ Applause ]
>> JOSH SHAFFER: 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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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]!
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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 --
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
[ Laughter ]
[ Applause ]
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
[ Applause ]