Transcript
[ Music ]
[ Applause ]
>> So, good morning, everyone.
So, my name is Tom Witkin,
and I'm an Engineer here
at Apple on watchOS.
And this morning, we're
going to be talking
about building quick
interactions
into your Apple Watch apps.
And first off, we'd like to
start with the question -
what do we even mean
by a quick interaction?
So I'm sure that many of
you have developed apps
for iOS or for Mac OS.
And on those platforms, we're
typically measuring the amount
of time a user is spending
in your applications in terms
of minutes or even hours.
But in watchOS, it's
just not the case.
But in watchOS, it's
just not the case.
A user wants to be able to raise
their wrist and quickly get
to specific information or
perform a certain action,
and then drop their
wrist and go back
to whatever they were doing.
And so the interaction
model is entirely different.
So here are some examples
of what a quick interaction
on Apple Watch are.
So, for example, starting a
timer, or checking the weather,
or marking an item
off your grocery list.
And so we think that these are
some of the prototypical types
of interactions on Apple Watch,
and there are some key
philosophies behind these
that you've probably
heard this week.
So, first off, apps
on Apple Watch --
they need to be glanceable.
Which means that,
with just a glance,
your users should be able to get
the information that they need.
Apps need to be actionable,
which means that your users
should be able to make quick
and well-informed decisions.
And lastly, they
should be responsive.
You should never be
making your users wait.
And if you're interested in
learning more about these,
I highly recommend
that you check
I highly recommend
that you check
out the Designing Great Apple
Watch Experiences talk this
afternoon, or watch the video
of the What's New in
watchOS 3 session.
And so now we know a
bit about what we mean
by a quick interaction.
But how long is a quick
interaction on Apple Watch?
And so we think that
the ideal length
of interaction is
only 2 seconds long.
So, 2 seconds.
That's not very long at all.
And so you have to be very
deliberate in how you design
and build your applications.
But we think that it's
more than possible,
especially with all the
new features and API
that we've added in watchOS 3.
And so that's how we're
going to start off --
is by talking about these
new features and API.
And then afterward,
we're going to look
at some practical techniques
that you can use in your apps
to build these types
of quick interactions.
And with that, I'd like to hand
the stage over to my colleague
to talk through the
new features and API.
[ Applause ]
>> Thanks, Tom.
Hi, everybody.
My name is Miguel.
I'll be giving you a quick
overview of the new APIs
I'll be giving you a quick
overview of the new APIs
that we're introducing
in WatchKit to allow you
to implement quick interactions.
I'll be talking about five
sets of API that allow you
to make your apps glanceable,
actionable, and responsive.
The first has to do with
giving you more access
to new kinds of input.
You can now do gestures
with gesture recognizers
in your apps.
We are giving you access
to the rotation events
in the Digital Crown.
And we're also having
three other areas.
One is for improved
table navigation,
the support for the new
user notification framework,
as well as integration with
SpriteKit and SceneKit.
So let's jump right in.
I'll be giving you an
overview of the API,
and then Tom will come back
on stage and show you examples
of how he combines
multiple of these APIs.
So if you have used
gesture recognizers in iOS,
you pretty much already
know all there is to know
for gesture recognition
in watchOS.
for gesture recognition
in watchOS.
If you haven't, gesture
recognizers are objects
that help you parse the
lower-level touch events
into recognizable gestures.
We're writing support
for four recognizers.
Two discretes -- the
SwipeGesture, the TapGesture.
And two continuous
gesture recognizers --
the PanGesture, and
the LongPress.
So the way you use this, like
most of the development you do
in WatchKit, is an interface
builder in your storyboard.
You are dragging the
objects into your interface.
So if you look at the library,
you can now see four
instances of the recognizers.
These are dragged into
the elements that you want
to have gestures
attached to them.
And you do the configuration
interface builder
in the inspector.
The last thing you do is drag
the action of the recognizer
into a function within
your code.
This is a function
that's invoked
This is a function
that's invoked
when the gesture is
recognized by the system.
As you can see, one
of the parameters is the
gesture recognizer itself.
From it, you can
now get the location
where the gesture
was recognized,
the bounds of the object,
as well as the state
that the gesture is in.
So, a few words about
the state of gestures.
Gestures begin in the possible
state before they're recognized,
and they can transition either
to a recognized or
a failed state.
When you're dealing
with discrete gestures,
you really don't think too
much in terms of states.
All you need to know is that
when the gesture is recognized,
your action method is called.
This is slightly different
from continuous gestures.
They also begin in
the possible state.
But as their name
implies, they progress
over multiple updates
into your code.
So just assume that your action
method will be called multiple
times as your gesture is
changing, giving you a chance
to update your user interface.
Some tips for using
gestures in watchOS.
We recommend that
you attach them
to the group elements
rather than the controls.
You can do that, but you
might conflict with some
of the gestures that are
already present in the controls.
And remember that you have
a smaller screen real estate
in the Watch app,
so the groups tend
to be the bigger interface
elements in your application.
You can still set dependency
relationships between gestures.
But for watchOS, this is only
possible in the inspector
and interface builder.
And be mindful that some
of the system gestures
will take precedence
over the gestures
that you will define.
For example, if you
have an element
that already has scrolling
enabled and you're trying
to attach a SwipeDown gesture,
that will not be recognized.
The scrolling will
take precedence.
The same thing for the
ForceTouch and the LongPress.
Now let's move onto our
second input element --
Now let's move onto our
second input element --
the Digital Crown.
This is a unique element
for the Apple Watch
that allows your users quick and
precise control of their input.
You've had access to the
Crown since watchOS 2
through the WKInterfacePicker
object.
To use that, you
are giving us a list
of picker items and
setting a style.
And WatchKit takes care of
drawing the element for you.
Here is the list style.
You have the stacks style
and the image sequence style.
But for this element,
WatchKit is taking care
of a lot of stuff for you.
We're drawing the
element, we're taking care
of interpreting the
Crown events,
and we're simply calling your
action when a selection is made.
So, in watchOS 3, we are
now giving you direct access
to the rotation events so
that you can write your own UI
elements and drive them
with the rotation values.
This is achieved
through two new objects
This is achieved
through two new objects
through new classes we're
introducing -- WKCrownSequencer,
which gives you access
to the rotation events --
I'm sorry, the rotations
per second.
And the new delegate
protocol, WKCrownDelegate,
with callbacks on
rotational deltas.
So you have two kinds of
values you're receiving --
rotations per second
and rotational deltas.
What do you do with each one of
them, or how do you access them?
If you're interested in
rotations per second,
you want to access the
crownSequencer property
which is now present in all
of the interface
controller classes.
And you query its rotations
per second property.
This is probably something
you're going to be using
when you're interested in the
speed of the Crown rotation
in maybe a physics-based
animation,
a game, something like that.
Rotational deltas are
communicated to you
through the delegate protocol.
This is how you're able to
count how many times the Crown
has rotated.
So you will get a callback
in the crownDidRotate method.
So you will get a callback
in the crownDidRotate method.
You will have the
rotationalDelta
as one of its arguments.
And what you want to do
in this method is you want
to maintain an accumulator
variable
where you add the deltas
that we're passing on to you.
The math you want to use
is a full rotation is equal
to accumulated deltas of 1.
Another example is if
you're only interested
in detecting half rotations, you
accumulate your deltas up to .5.
So you're adding the deltas
as we give them to you.
And when they cross
this threshold,
you know that a rotation
has occurred.
It's really up to you to figure
out how these rotation counts
correspond to the sensitivity
of the content that
you want to display.
When we're communicating values
to you, keep in mind the sign --
either positive or negative.
When your users are
scrolling with the intent
of moving their content up,
we will be giving
you positive values.
And when they're
scrolling with the intent
to moving the content down,
we're giving you
negative values.
And these values are orientation
agnostic, so you don't have
to worry about what
counter-clockwise
or clockwise means.
If your users change their Crown
orientation, we will continue
to give you a positive value
or a negative value for up
and down, so you don't
have to worry about that.
Finally, there's a concept
of focus on the Crown.
The focus can be taken away
by other interface elements --
for example, a picker, a
slider, any scrolling element.
So it's up to you to determine
when your interface
element needs
to be the focus of the Crown.
This is a great place to
be using the new gestures.
And once you determine that
your element needs to be
in focus again, please
call the function "focus".
And don't forget to
call this initially
when your interface
controller first comes up.
Now let's put aside the input
elements and let's talk a lot
about the vertical paging
that we're introducing.
about the vertical paging
that we're introducing.
The typical way that your users
navigate in your tables is
by selecting a row
and seeing the detail
for that particular row
in a separate controller.
They need to navigate
back into the master table
to select another row before
they're able to see that detail.
In watchOS 3, we have the
vertical paging concept.
So when you enable this in
your tables, once your users go
into their first detail, they're
able to swipe with their fingers
or with the Crown up and down
and see the subsequent
row detail.
So this eliminates their need to
go back into the master table,
making your app seem
a lot more responsive.
So how do you opt
into this mode?
It's actually pretty
straightforward.
All you need to do is enable
the Item Pagination checkbox
in your table inspector.
But you also need to make sure
that your table is
using the segues API.
that your table is
using the segues API.
That's where you're giving
us what context you want
to instantiate a controller
with and we instantiate it
with the given context.
You're probably already
doing that.
So the API itself
hasn't changed much.
There's a couple of changes.
There's a single method
that allows you to jump
into the segue mode from code.
This is useful when you're
launching your application
from tapping on a complication
or tapping from a notification
and you want to directly go
into a specific row
in the segue mode.
The second thing you need to be
aware of is WatchKit is trying
to be smart and help you
out with the speed
of your application.
So we're doing preheating
of controllers,
anticipating what the
user could do in terms
of scrolling up and down.
So some of the lifecycle methods
for your controllers will be
called before your elements are
on screen.
I won't be going too much
into detail about this.
But we have a whole new session,
Architecting for Performance,
where they give a
fairly detailed example
on all the badging of
the lifecycle methods.
on all the badging of
the lifecycle methods.
Now let's talk about
notifications.
These are the ultimate
quick interactions
that we've introduced
since the beginning
of the Apple Watch product.
So from a user's point of view,
your user's point of view,
the way they interact with
notifications is simply
by feeling the haptic
in their arm.
They raise their wrist and
they automatically see this
short-look interface
for your notification.
If they keep their hand
raised, we transition
into the long-look
of the notification.
The way they respond to
your notifications is --
I'm going to walk through
the long-look example,
which is the one that
has the most detail here.
So if you've done
a good job in terms
of communicating the
content of your notification
through the text,
they'll do nothing other
than dismiss the notification.
That is the shortest
quick interaction.
That is the shortest
quick interaction.
They could also tap on the
notification to launch your app.
Or, remember that notifications
can have custom actions
associated with them.
In this case, I'm
showing three --
the Accept, Maybe,
and Decline button.
You can have up to
a total of four.
When you're associating
actions with your notifications,
they can either be
foreground actions --
meaning that if the
user taps on the button,
your application will become
active -- or background actions.
Background actions in watchOS
2 were always forwarded
to your phone.
The big change in watchOS
3 for a notification is
that there's a whole new
notification framework.
Please go to the Introduction
to Notifications session
to learn all of the details
about the new framework itself.
But the high-level
points for you
But the high-level
points for you
as WatchKit developers
are three.
You now have a set of
similar notification APIs
across platforms --
iOS, tvOS, and watchOS.
You can now schedule local
notifications on your watch.
And notifications
with background actions will now
be delivered to your extension
as long as they were
scheduled on the Watch.
Let's look at the API.
The new object,
UNUserNotificationCenter,
you want to become the
delegate of that object probably
when your application
is launching
in the
applicationDidFinishLaunching
method.
And you want to indicate
that you are adopting
the notification center
delegate protocol.
There are two methods
of interest
to you in this protocol.
The first is the
willPresent method.
This is called when your
application is already active
on the watch face and the system
is giving you an opportunity
on the watch face and the system
is giving you an opportunity
to tell it how you want it
to handle that notification.
So, depending on the
option that you use
in the completion handler there,
the system will do
one of two things.
If you say that you want
to use the alert option,
we will revert back to the
regular long-look interface
for the notification and it will
be overlaid on top of your app.
If you say that you
want to do nothing,
that means that system
should do nothing.
Since your app is
already active,
you are the ones taking care
of displaying the
notification content somehow
in your application.
The second method is
the didReceive response.
This is when your users
act on your notification.
So this is the callback when
the app becomes foreground
because the user
tapped on a button.
And this is also the new
entry point in watchOS 3
where you're getting a
callback for background actions.
But, remember, this is
only for background actions
that are scheduled
on the Watch itself.
that are scheduled
on the Watch itself.
This is a good moment to make a
quick review of the scheduling
and delivery of notifications
on Apple Watch.
Anytime a notification fires
on your phone, it is forwarded
to the Watch if the
screen on the phone is off
and you have your Watch on
your wrist and it's unlocked.
That's always been the behavior.
But now in watchOS 3,
you have the ability
to schedule your
own notifications
on the Apple Watch.
So keep in mind that these are
only delivered on the Watch.
And if your application needs
to also have a corresponding
notification on the phone side,
it's up to you to
communicate to the phone
and schedule your
notification there.
Now you might be wondering,
"If I schedule multiple
notifications,
what happens when
they both fire?"
Well, you have the ability to
dedupe the notifications as long
as you use the same identifier
both on the Watch side
and on the iPhone side
of the notification.
and on the iPhone side
of the notification.
So if we're in a situation
where we're forwarding the
notification to the Watch,
we look at the ID first.
And if there's a similar
ID notification firing
at that moment on the Watch,
that is giving precedence
and that's the one
that's displayed
so your users don't see two
things fire at the same time.
Finally, let's talk about the
SpriteKit and SceneKit objects.
So SpriteKit and SceneKit are
very rich APIs that allow you
to do the 2D and 3D
graphics, and they allow you
to expand significantly
the visual language
of your applications.
We have two new classes
for WatchKit
that support these frameworks --
WKInterfaceSKScene for SpriteKit
and WKInterfaceSCNScene
for the SceneKit.
Again, you do all of the
configuration in the storyboard
and interface builder.
You will now see the two
classes appear in the library.
You will now see the two
classes appear in the library.
All you do is drag them
into your controller,
and they really pretty
much give you the canvas
where you're going to
be drawing your scene.
And the configuration
is done on the inspector
and interface builder.
Once you're ready to
display your scenes,
all of your SpriteKit
and SceneKit code
continues to be that.
You continue to use the APIs.
I won't be going into the APIs
of those frameworks themselves.
But once you have your
scene ready to present,
the integration with
WatchKit is simply
in the presenting of the scene.
So if you're dealing
with a SpriteKit scene,
you call the percent function
or functions depending
on whether you have
a transition.
And if you have a
SceneKit scene,
all you do is set the scene
property on the object.
And that's all there is in
terms of the integration.
So I've given you
a quick overview
So I've given you
a quick overview
of the new ToolKit
items that you have
for creating glanceable,
actionable,
and responsive applications.
Now Tom will come back and
give you specific examples
of how he combines
multiple of these interfaces
to make your app
more responsive.
Thank you.
[ Applause ]
>> All right.
And so now we have that
ToolKit, so we can look
at some practical techniques
to actually build these types
of quick interactions.
So we're going to talk
through adding complications
and notifications in your app.
And now these are not new, but
we're going to talk through them
in some unique and new ways.
Then afterward, we're
going to talk
about having a simple navigation
model within your apps.
And then lastly,
we're going to talk
about giving your users the
confidence to drop their wrist
as soon as they're
done interacting inside
your applications.
And so we'll start off with
actionable complications.
And so we introduced
complications
for third-party apps
in watchOS 2.
And now in watchOS 3, they're
playing an even larger role.
And now in watchOS 3, they're
playing an even larger role.
And now there are more faces
that have complications,
and there's some of
the existing faces
that have even more
complication slots.
So, also, now you have the
ability to quickly swipe
across your faces to see
all your complications.
So because of this, we
think that every app
on Apple Watch should
have a complication.
And you'll now see that all the
native apps have complications
as well, as you can see
with the Workout app
or the Heartrate app.
So why complications?
They're extremely glanceable.
They're on their
wrist at all times.
And with just a glance,
you can see a lot
of really important information.
They are frequently updated.
If your app has a complication
on the current face,
it's updated at least
twice an hour.
And so you can always ensure
that you have really fresh
and current data always
available to your users.
Your app is kept in memory.
And this is really important
because it makes the launch
of your app extremely fast
and makes all the interactions
within your applications
a lot more responsive.
within your applications
a lot more responsive.
And complications
provide a great way
to accelerate your
users into your app
to perform specific
types of functionality.
So, for example, if we look
at the Music complication,
I tap on that and
I'm sent directly
to the Now Playing screen
because that's what's
most important
to me if I'm playing music.
I can play and pause the
song or skip the track.
And it makes the whole
interaction a lot faster
because I'm sent
directly to where I need.
Also new in watchOS 3 and
iOS 10 is the new Gallery
in the Apple Watch
app on iPhone.
This is great because
it allows you
to add new faces to
your Apple Watch.
But it also allows you
to customize the faces
and choose among all
the complications.
And third-party complications
appear here as well,
so it's a great way
for your users
to discover your complications
and add them directly
to the watch face.
And if you want to be part
of the list of complications,
you create a complication
bundle.
And there's documentation for
that on the developer website.
So I highly recommend
that you check that out.
So complications on Apple Watch
are just a really fantastic
mechanism to get your
users into your app
and really provide a lot
of these fast interactions.
So if you don't have a
complication in your current app
or you're building a new app,
make sure to include them.
Next up, we're going to move
onto glanceable notifications.
And so we all know
that notifications
on Apple Watch are
really fantastic,
and one of the main reasons is
that they're entirely
customizable.
And so you can make them
look however you want.
But also, it allows you
to display really valuable
information right inline
in the notification.
So, for example, here in
the Calendar notification,
I can see the name of the event
and when it is and where it is.
And ultimately, this can often
times remove the necessity
to even go and launch
the Watch app
because all the important
information is right inline
in the notification.
And now in watchOS 3, all
notifications support SpriteKit,
and SceneKit, and inline video.
And so you can provide even
more customization inside
of your notifications.
So, SpriteKit and SceneKit --
I'm sure a lot of you think
of these in terms of gaming.
And they're great for gaming.
And there's a session on Friday
about game technologies
for Apple Watch.
But here, we'd like to
talk about them in terms
of nongaming types
of interfaces.
And so why are they
important for nongaming?
They allow you entire
customization over the content,
and the layout, and the
animation of your interfaces.
And so it allows you to create
really custom types of looks.
And so, here, we're
going to look
at an example of a Photos app.
So, here, you can see I got a
notification from my friend,
Ivy, and she has shared
some photos with me.
But this does not include
a lot of information.
I have no idea what
the photos are.
I have to read the text in order
to see who has shared them.
And so we can definitely
take a lot more advantage
of the customization
possibilities
in our notification.
So here's an alternative
which is now using
SpriteKit along the top.
It actually has the photos
that were shared with me.
It has the photo
of my friend, Ivy.
And with just a glance, I can
see a lot more information.
And ultimately, I can make a
more well-informed decision
on whether I want to go launch
the Watch app or even go
and grab my iPhone and
check these photos out more.
And if we look at
how this was done,
across the top we have the
new WKInterfaceSKScene object.
And then below that, we
just have a regular label.
And the key thing I want
to point out here is
that you can mix and
match your SpriteKit
and your WatchKit user
interface elements.
And so maybe you already
are using an animated image
or the view animation API.
You can swap those
out with SpriteKit.
Or if you just have an
existing interface and want
to add animation, you don't
have to rewrite everything
in order to adopt SpriteKit.
So it provides a really powerful
way to add a lot of richness
to your interfaces without
having to throw everything out
and start over, which
is really cool.
And so if you have
notifications within your app,
make sure to take full advantage
of what they have to offer.
If you just kind of have
the default interface,
think about what information
is really important inside the
notification and add a custom
interface to reflect that.
notification and add a custom
interface to reflect that.
OK. So, next up, we're moving
on to a simple navigation
model within your app.
Earlier, we talked about the new
vertical paging API for tables.
And that's great for
any hierarchical app.
But here, we'd like to talk
about navigation in terms
of two other of the technologies
that we talked about --
and those are Gestures
and the Digital Crown.
And so the Digital Crown
is unique to Apple Watch,
and it's a really
fantastic input mechanism.
It allows you to quickly
and precisely interact
with the interface.
And it can be used in
many, many different ways.
So, for example, in the Timer
application, it can be used
to scrub through durations
and choose the time you want.
Or in the Photos application,
it can be used to zoom
in and out of the photo.
So you can get really creative
with how you use the Digital
Crown in your applications,
and we're really excited to
see how you'll be doing that.
And here, though, we'd like
to talk through an example
of a running app that puts both
Gestures and the Digital Crown
to use to simplify
the navigation.
to use to simplify
the navigation.
So, here, we have one
version of a running app.
The goal is to show my
previous run, and to show kind
of the average time, and
distance, and the altitude.
So one version is just to kind
of have a list of every mile.
And maybe I can tap in on the
mile and see more information,
or I can scroll the list
and see the entire run.
And while this version
has all the information
that I would need, you kind of
have to hunt around in order
to find what you're looking for.
You have to tap in on rows,
you have to scroll the list,
and the information just isn't
that dense or glanceable.
And so it can definitely be
done in a lot better way.
So here's an alternative
which now is using SpriteKit
to have a graph at the top,
and it shows the entire run.
And so with just a glance,
I can actually see a lot
more of the information.
And now with the use of
gestures, I can tap on the graph
and it will animate between
the pace and the altitude.
And then I can also use
the Digital Crown to scrub
through the graph to
specific data points.
So even though there's a lot
more information on screen,
it's actually a lot
easier to navigate
it's actually a lot
easier to navigate
to the specific information
that I'm looking for,
and it makes the overall
interaction a lot faster.
And so, as you can see
now, we're starting to mix
and match all the technologies
that we introduced earlier --
so Gestures, and the Digital
Crown, and SpriteKit --
and they create some really
powerful combinations.
So as you're building
your own applications,
you should make sure to take
into account all
the technologies
and see how they can help
to simplify the navigation
within your app.
A lot of focus has gone into
navigation in watchOS 3,
and we really want to
make sure that carries
through to all of
your apps as well.
And so, last up, we're going
to talk about a technique
that allows your users to
drop their wrist as soon
as they're done interacting.
And so a key aspect in
making a quick interaction
on Apple Watch is that your app
feels very, very responsive.
And this is especially true
if you're doing any type
of networking or communicating
with a companion iPhone.
Because often times,
that can lead
Because often times,
that can lead
to loading indicators,
which are not good.
And one aspect of this is
if you're updating the
data within your app.
And that's a large enough topic
that there's actually
a whole talk
on keeping your Watch
app current and fresh.
So make sure and check that out.
But here, we'd like to talk
about networking in terms
of responding to user action.
So, for example, you have a
food-delivery app, and you want
to buy some food and
you tap the Buy button.
How does your app respond
in that type of situation?
And we want to recommend that
you provide instant feedback
to your users rather than
showing a loading indicator.
So we'll walk through an
example of what that means.
So, here, we have that
food delivery app I was
talking about.
I can tap on one of
my favorite items
and there's a big Buy button,
and so we think this is going
to be a really fast
and quick interaction.
And I tap on Buy and I
get a loading indicator.
And that's because the app has
to go talk with the server,
it has to process the order, it
has to get that confirmation.
And then once it's done that, it
has to send back to the Watch.
And then once it's done that, it
has to send back to the Watch.
And only then is it going to
remove the loading indicator
and say, "Hey, your
order is on its way."
And if we look at
a timeline of this,
it really shows the problem.
Right? We start with
choosing the item.
We tap Buy.
And then we show the
loading indicator.
And during this time, the
user just raises their wrist
and stares at your app until
you can show that confirmation.
And so the user is only
actively interacting with this
at the beginning and the end,
and so most of the time
is just spent waiting.
So we can definitely improve
on this type of interaction.
So, alternatively, if we
go back to our food app
and now we tap the Buy button,
we have instant feedback.
The key thing here is
this isn't confirmation
because we haven't
done any networking.
We can't actually say
the order is on its way
because we have no idea.
But we want to provide
this feedback
and ultimately give
the user confidence
that the app is taking
care of their order.
And this allows the user then
to go and drop their wrist
and not have to wait
on the application.
And now, in the background,
the app will use a background
NSURLSession to go talk
with the server, and then
eventually gets a response.
And then, in the background,
the app is woken up
and it can use the new local
notification support to say,
"OK, now your order
is actually confirmed.
It's on its way."
And then you have all the same
information that you had before.
And looking at a
timeline of this,
it really shows how much it
helps and improves things.
So we choose an item,
we tap Buy,
and so we start out
the same way.
And then instead of showing
the loading indicator,
we show the feedback.
And then after we
do the networking,
we show the notification.
And so as far as the
app is concerned,
the overall interaction
is actually about the same
as it was in the first example.
But from the user's point
of view, it feels far faster
and far more responsive.
And so it's just a better
interaction overall.
I do want to point out here
how you can actually do
that processing after the
user has dropped their wrist.
If you're doing networking,
you can use a background
NSURLSession.
you can use a background
NSURLSession.
And make sure to
use a download task
because that will enable
your app to be woken
up in the background
after it's been done.
And then at that point, you
can do a local notification
that makes sense in
your application.
Or if you have to do
processing on the Watch itself,
you can take out a
background task assertion.
We had a great walkthrough
of this
in a session last year called
WatchKit Tips and Tricks,
so make sure to check that
out if you need to do any type
of processing on
the Watch itself.
So 2 seconds is a very
audacious goal in terms
of how fast interactions
on Apple Watch should be.
But we really think that
it should be the goal
as you're building
your applications
because it can really inform
how you design and build them.
So as you're going about
creating new applications
or thinking about your existing
ones, make sure to focus
on quick interactions right
from the very beginning.
And think about what
are the features
that your users are
going to want to be using
in your applications, and make
sure that those are surfaced
to the very front and are
really fast and responsive.
Use complications
and notifications
Use complications
and notifications
because they just create really
fast interactions overall,
and they just provide a lot
more utility to the user
for your applications.
Use SceneKit and SpriteKit
to create really rich
but also interactive
types of interfaces.
And they can add a lot of power
to your existing
apps or new apps.
And so we're really excited
about what you're going
to be doing with those.
Simplify the navigation.
Again, a lot of work
has been done in watchOS
to simplify the navigation
at a system level.
But we also want that to
carry through within all
of our applications as well.
And, again, never
make the user wait.
If you're showing a
loading indicator on screen,
try and reorganize your app
to allow the user
to drop their wrist.
Provide the instant
type of feedback,
and just give the
user confidence
that your app is
taking care of things.
And so for more information on
anything that we talked about,
go and check out the
developer website.
And there are tons
of sessions all week.
I highly recommend the Designing
Great Apple Watch Experiences
I highly recommend the Designing
Great Apple Watch Experiences
talk this afternoon or the
watchOS talks tomorrow as well.
With that, I want to
thank you all for coming.
And enjoy the rest of the
week in San Francisco.
[ Applause ]