Transcript
[ Music ]
[ Applause ]
>> Hello. Good afternoon and
thank you for coming to What's
New in WatchOS.
In this session, we're going to
give you a high-level overview
of the new features you as
developers, designers and
product leaders can take
advantage of to create great
Watch experiences.
And we're also going to dip into
the details of the new APIs and
interface builder options.
My name is Lori Hylan-Cho, I
work on the Watch frameworks
team, and I am beyond thrilled
to be here, to share with you
the awesome new options for
creating great Watch experiences
in WatchOS 5.
We've come a long way since our
humble beginnings in 2015.
And a great Watch experience now
consists of several components,
of which a Watch app is likely
to be only one.
Notifications, complications and
Siri shortcuts work together to
create a Watch experience that
allows for brief and meaningful
interactions with the right
information at exactly the right
time.
And of course, with Series 3
Watches that support cellular,
and the new Wi-Fi options that
let you join networks directly
from the Watch, more and more
Watch wearers are venturing out
without their phones.
So, it's important to create a
Watch experience that feels
complete.
Let's take a look at the
features we've added to WatchOS
5 to help you deliver this kind
of a great experience on the
wrist.
Ask any Apple Watch user what
they like most about their
Watch, and one of the first
things they'll say is
notifications.
We're making notifications even
richer this year with a few key
improvements.
Creating dynamic notifications
with images and text has been an
option since WatchOS 1.
But if the user missed the
notification when it arrived,
chances were they'd never see it
at all, as the Notification
Center would display the static
version.
This was intentional, as we have
more time to display the
notification when it arrives
than we do when displaying it
from Notification Center.
In WatchOS 5, we'll do our best
to show that beautiful dynamic
notification with no code
changes or recompilation
required on your part.
We worked hard to make this
possible for its own sake but
being able to show dynamic
notifications from Notification
Center also makes possible the
next two features I'm going to
tell you about.
The first of these is grouped
notifications.
You probably already know that
you can have multiple categories
and different notification
interfaces for each one.
And you might already be
specifying a thread ID and the
push notifications that get
forwarded from iOS to the Watch.
In WatchOS 5, this will cause
notifications to be grouped
automatically in Notification
Center as you saw in the
previous slide.
Specifying a category and thread
ID also opens up another
possibility.
Getting the same behavior as the
built-in messages app, where new
notifications with the same
thread ID that come in when the
original one is still on screen
are appended to the existing
interface.
We made this kind of grouping
behavior optional to give you a
chance to handle being called
multiple times for the same
notification interface
controller.
To opt into this behavior,
select your notifications
category in the interface
storyboard for your Watch app.
And check the handle's grouping
box in the attributes inspector.
If the original notification is
on screen when additional
notifications that have a
matching category and thread ID
arrive, did receive notification
will be called again on the
existing notification interface
controller.
So, you should be prepared to
append content to the existing
notification interface.
Perhaps by adding a blank line
and the new body content to an
existing label.
Or by adding a new row to a
table, as you saw on the
previous example.
And speaking of did receive
notification, its signature has
changed in WatchOS 5.
This version, with the
completion handler has been
deprecated, in favor of this
simplified version.
We did this, so we'd have a
clear boundary for when you're
done processing your
notification data.
And we'd know that everything is
ready to be shown on screen.
We encourage you to do only the
work necessary to display the
notification and to do it as
quickly as possible.
By the way, it's not necessary
for the user to keep their wrist
up to see all the notifications
with the same thread ID as they
come in.
If you're handling grouping and
the dynamic interface for your
notification category, all the
messages with the same thread ID
will expand to a single platter
when the user taps on the group
and Notification Center.
And if additional messages on
that thread come in, they'll be
appended live is when the long
look was first on screen.
So, here's a big one.
In WatchOS 5, you can now bring
some of your apps' functionality
directly into the notifications
you send by including elements
that let the user interact with
content in the notification
itself.
For example, you could let a
user pay for their ride and rate
their driver, notify a user that
their meter is about to expire,
and let them extend their
parking time, or give a diner an
opportunity to not only confirm
their dinner reservation, but to
let you know they'll be a party
of three instead of four.
So, let's see how all this
works.
If you're creating a new
notification interface
controller, a dynamic
interactive interface will be
created for you automatically.
If you already have a dynamic
interface for your notification
category, select the category in
your Watch App's interface
storyboard and check that has
interactive interface box.
In both cases, you'll notice
that the old dynamic interface
is still there, in addition to
the dynamic interactive one.
The dynamic interface will be
shown in WatchOS 5 when the
notification first arrives, and
now in Notification Center as
well, as I mentioned before.
The dynamic interface will be
shown in earlier versions of
WatchOS so, you'll want to keep
that one around for backwards
compatibility.
Once you have a dynamic
interactive interface controller
you can add buttons, switches
and other interactive elements
in the object library, which is
now available at the top of the
screen as a popover menu.
You can even add gesture
recognizers with your
notification, though you should
be aware that the system
gestures will take precedence
over any gestures you add in the
same areas.
Once you've designed your
notification interface wire up
the interactive elements to your
code, the way you would any
other interactive element in
your app.
As you can see here, I'm
dragging my IB action for up
button tapped to the button in
my dynamic interactive
interface.
So, the amount of time will
increase by 15 minutes every
time the button is tapped.
And with all this button tapping
you may have already forgotten
that notifications have always
launched your app when tapped.
This is still true for a regular
dynamic and static
notifications.
But, we obviously had to disable
this behavior for dynamic
interactive notifications.
Because we have interactive
elements in them now.
You can still launch your app
from an interactive
notification, if you need to.
You just have to do it
explicitly by calling a new
method, performed notification
default action.
Similarly, if you include a
button in your notification
interface that should dismiss
the notification after taking
action, as in this case where
tapping the extend button should
both commit the changes to my
rental time and dismiss the
notification, you do this by
calling perform dismiss action
at the end of the IB action
function associated with the
button.
You could also process the
changes made in the body of the
notification using a standard
action button.
Since action buttons always
dismiss the notification.
Wait, you're probably thinking,
action buttons are shared
between all the notification
interfaces.
And some of those buttons
wouldn't make sense if the
interactive elements weren't
there.
Well, new in WatchOS 5, you can
now adjust the action buttons
that are shown at runtime.
There's a new notification
actions property on the
notification interface
controller that returns the
array of actions that will be
displayed for the notification.
You can set this property to a
new array of UN notification
action objects in your did
receive notification call back.
which gives you the flexibility
to add or remove buttons to suit
your interactive interface.
And in an upcoming seed, we're
going to allow changes to
actions any time after did
receive notification is called.
Which will give you the
flexibility to change the action
buttons based on how the user
interacts with the elements in
the interactive notification
interface.
So, that's a lot of information
about notifications and the
options for creating them so
far.
But I have two more things to
tell you about before we move
on.
Critical alerts are a new kind
of notification that will cause
a prominent haptic and a sound
to play even when your Watch is
silenced or in do not disturb
mode.
And thus, they can be used to
deliver extra urgent
information.
If your Watch app integrates
with a medical device or is used
by emergency responders, this
kind of alert might be for you.
Critical alerts require an app
entitlements and explicit
permission to be granted by the
user separate from regular
notification.
The opposite of a critical alert
is one that can be delivered
quietly.
That is, rather than
interrupting the user with an in
the moment notification that
takes over the screen, you can
now choose to send notifications
directly to Notification Center.
You'll notice that no indicator
will appear unless a prominently
delivered notification is also
in Notification Center.
But the swipe from the top of
the screen will still reveal the
quietly delivered notification.
If you choose to deliver
notifications quietly in your
app, you don't have to prompt
the user to allow notifications
when the app is first launched.
Instead, you can request
provisional permission.
This gives the user a chance to
see what kinds of notifications
your app sends before having to
decide whether they want to see
them as they arrive.
Whichever option you choose as a
developer, the user still has
ultimate control over how they
receive your notifications.
They can choose to deliver
notifications quietly by swiping
left from a notification in
Notification Center or change
their notification preferences
in settings.
To sum up, notifications are now
more dynamic.
Users will see your dynamic
interface from Notification
Center in addition to when the
notification first arrives.
We're also offering grouping by
thread ID for the first time on
the Watch.
So, you can design notifications
that behave like the ones like
the built-in messages app.
You can now bring more of your
app experience directly into the
notification your app delivers
with interactive controls and
action buttons that can be
defined at runtime.
And you can also choose to
deliver notifications with the
appropriate level of urgency.
To learn more about
notifications you can attend one
of these sessions.
I highly recommend Designing
Notifications, that will give
you some great tips for how to
design effective interactive
notifications.
Okay, now that we have your
user's attention with
notifications, let's turn our
attention to the features we're
adding to make your Watch apps
more awesome.
The first has to do with local
audio playback.
Some of you have already made
forays into audio playback on
the Watch by taking advantage of
URL session for downloading
files to the Watch.
And WK audio file queue player
to play them.
With WatchOS 5, we're going to
make developing audio apps for
the Watch even easier, and the
resulting experiences more
delightful.
In WatchOS 5, we're offering a
new background mode for playing
local audio files.
So, you can now focus on your
app's main purpose, audio,
rather than trying to figure out
how to build something else like
a workout app just to be able to
play audio.
[ Applause ]
We also exposed AVAudio player
and AVAudioEngine directly,
which means you can use the same
methods and properties you're
already familiar with if you've
been building iOS apps that play
audio.
In fact, you can share your code
between your iOS app and your
Watch app by moving your
playback related code to a
framework.
One thing that's different from
iOS, is that playing longform
audio on the Watch requires
headphones or an external
speaker to be connected just as
when playing from the built-in
music app.
For this reason, Bluetooth
routing is part of the session
activation process.
If you set your route sharing
policy to longform, as you
should, will automatically
connect to the headphones with
Apple wireless chip, like
AirPods or Beats Studio3, if
they're already in use.
Or, will show a route picker to
let the user choose other
headphones or Bluetooth speakers
when you call the activate with
options completion API in a
session that's new.
You could also use the MP now
playing info center API to
populate the now playing app
with information about what your
app is playing.
Which means your apps info will
show in the now playing
complication.
And you can handle the media
remote commands that make sense
for your app; from play and
pause, to next and previous, to
even like and dislike.
And last, but not least, it's
now possible to control the
volume from your custom playback
UI with the new volume control
view.
Available in the object library
and interface builder.
[ Applause ]
The control automatically takes
on the tint color of your app
when at rest and responds with
the color changes you're used to
from the system volume control
when turning the digital crown.
There's a whole session devoted
to creating audio apps for
WatchOS which I highly encourage
you to attend to get more
details about the new APIs and
best practices for working with
audio.
And we'll also be prepared to
talk about background audio at
the WatchOS runtime and
conductivity lab on Thursday.
If the primary function of your
app isn't playing audio, but
your app would benefit from
being able to control audio
playing elsewhere on a system,
whether it's on a Watch or on
phone, as in the workout app,
where you can swipe left during
a workout to see now playing
controls.
You'll be happy to hear that
were exposing a now playing view
that you can embed in your apps.
You can find the now playing
view in the object library in
interface builder.
It's designed to fill the
screen.
So, it works best in apps with
page layouts.
Note that the now playing view
is a systemwide control that's
meant to control audio coming
from other apps.
So, it will show whatever the
user is currently listening to,
whether it's on Apple Watch or
iPhone.
While we're here, I want to
point out a couple of other new
options and one change in
behavior.
In previous versions of WatchOS,
if you added a 38-millimeter
asset but forgot to add the same
asset for a 42-millimeter
device, the asset would be
missing on the larger device.
Now it will automatically fall
back to the 38 millimeter size
if the 42 millimeter size is
missing.
But you can skip worrying about
providing assets of different
sizes altogether by instead
adding a PDF in the universal
selection of your asset catalog
and setting the new auto scaling
option to automatic.
This will cause the right sized
asset to show up at the right
place at the right time.
We've also exposed the title
textiles in the font menu to
give you more options for
differentiating your text within
your interfaces.
These textiles are compatible
with dynamic type, so they'll
increase or decrease.
They'll scale up and down, as
the user changes their font size
in settings.
And the large title style is
available in both interface
builder and as an API.
Since I'm in the process of
building an app for skating
workouts, now would be a good
time to talk about the
improvements we're making to
workouts in WatchOS 5.
We completely rewrote the
workout API in this release to
make it simpler, more reliable,
and more resilient.
And we've moved the built-in
workout app to use it.
We're hoping you'll move your
fitness apps to it to.
It's now easier than ever to
start a workout and collect the
right data with a new
initializer from HK workout
session and the new workout
builder API.
You create the workout session,
get the builder from the session
and start collecting data.
It's that simple.
This is what it looks like in
code.
You create and configure the
session with a health store and
a workout configuration, which
includes the activity type.
Grab the HK live workout builder
that's associated with the
session and begin collection.
The relevant data for the
workout type will be collected
automatically, even across
pauses and resumes, to give you
a correct and consistent HK
workout artifact with a correct
elapsed time.
And because no app is perfect,
if your fitness app crashes
during an active workout session
it will automatically be
relaunched.
[ Applause ]
Just use the HK health store
recover active workout session
API and the session and builder
will be restored in their
previous state.
To learn even more about the new
workout APIs, as well as options
for collecting health and
fitness data check out New Ways
to Work With Workouts or visit
the health and fitness
technology lab tomorrow
afternoon.
Next up, your apps now have a
place on the Siri Watch face
with Siri Shortcuts.
As you saw on the keynote, Siri
Shortcuts are meant to help
users accomplish tasks that they
perform frequently with more
ease than ever before.
And the Siri Watch face surfaces
these, the common tasks, at the
right place and time with a
little input from you as app
developers.
I want to focus on how to use
shortcuts to make a great Watch
experience and how that
experience differs depending on
whether your Watch app is
installed.
First, a few words about what
makes a good shortcut.
As the name implies, shortcuts
are about helping Watch users
see useful information and
perform common tasks quickly.
Whether it's launching your app
to a specific screen with
options preselected, or getting
to the awesome outcome your app
enables, such as ordering your
morning coffee, booking a fine
dining reservation, or re-upping
your chocolate supply.
Think about glanceable
information and one or two tap
interactions.
Shortcuts can be user activity
based, or intent based.
User activity based shortcuts
are great for when the goal is
to launch your app with a
specific context, such as
navigating straight to a screen
where the user can log a meal
they've eaten, or in this case,
delivered.
Intent based shortcuts make more
sense for tasks that don't
necessarily require your app to
be launched.
Such as placing your regular
coffee order.
If your shortcut is
intent-based, when the user taps
your shortcut platter on the
Siri face, they'll receive a
quick confirmation screen.
Did you mean to order that
coffee?
If the intent supports
background execution, it will
run without launching the app,
when the user confirms.
Otherwise, the confirmation will
launch or restore the app and
hand it your intent.
How the user has interacted with
your app in the past is taken
into account when predicting
what shortcuts to show.
You should donate intense or
user activities as the user
performs the main functions of
your app.
For example, an audio app like
Audible would donate an IN
media, play media intent when
the user starts or resumes
playing an audiobook.
Shortcut surface on the Siri
Watch face based on relevance
with the most relevant items
appearing at the top of the up
next section and less relevant
ones at the bottom.
Previous user interactions
intense performed or donated and
user activities that have been
marked both eligible for search
and eligible for prediction
inform relevance.
But to appear on the Siri Watch
face, you must also give the
system explicit hints about when
or where a shortcut is relevant
by creating a relevant shortcut.
A relevant shortcut consists of
a user activity or intent-based
Siri shortcut, an optional Watch
template that defines the title,
subtitle, and image that should
appear in the shortcut platter,
and an array of relevance
providers that define the time,
location or situation in which
your shortcut would be most
relevant.
We've already talked about user
activity and intent-based
shortcuts, so let's talk about
the other two components of a
relevant shortcut.
A Watch template is an optional
IN default card template, that
consists of a title, an optional
title, and an optional image.
If you don't provide a Watch
template, we'll pull the
necessary information from the
IN shortcut, but you should take
the opportunity to provide
informative strings so the user
understands what they get when
they tap your platter.
A relevance provider focuses on
the date, location or situation
in which the shortcut would be
most valuable.
Think about when and where your
shortcut would be relevant.
Is it something the user might
glance at or tap on at any time
during the day?
Is it relevant at a specific
date and time, or is it based on
location?
Since a relevant shortcut takes
an array of relevance providers
it's possible to specify more
than one kind.
For example, if your shortcut
would be relevant at both a time
and a place.
Again, these relevant providers
act as hints to the system.
As the user interacts with your
content, actual usage will
inform its placement.
If the user fails to interact
with shortcuts that appear on
the Siri face, they'll drop in
relevance.
Once you have relevant
shortcuts, the next step is to
supply them to the relevant
shortcut store so they can be
considered for the Siri Watch
face.
Relevant shortcuts can be
supplied by both your iOS app
and your Watch app.
iOS relevant shortcuts are
synced periodically from iPhone
Apple Watch and they're merged
into consideration with the
Watch relevant shortcuts.
If your Watch app supports the
iOS shortcut, the Watch app
handles execution.
If it doesn't, or if the Watch
app is not installed, the
shortcut executes on the phone,
over Internet.
A subset of relevant shortcuts
can surface on the Siri Watch
face, without Watch OS support.
If they are intent-based
shortcuts that support running
in the background and can run
without accessing encrypted
data, which is separate from
off.
Again, these shortcuts are going
to execute on iPhone over
Internet.
The richest experience for users
will always be with a Watch app
that can handle the shortcut
locally, either by launching the
app or by executing the intent
in the background.
You'll want to update your
relevant shortcuts periodically.
If the user launches your app,
for example, by tapping one of
your shortcuts on the Siri face,
you'll have the run time to
accomplish the update.
But shortcuts that provide
glanceable data are useful to
the user without launching the
app.
Think about the carrot whether
example from a couple slides
ago, were you could tell that it
was 72 degrees and cloudy just
by looking at the platter.
You didn't have to tap.
To help with this case, we added
a background refresh task called
WKRelevantShortcut
RefreshBackgroundTask.
When you get this task before
sure to check if your data needs
to be updated and then supply
new relevant shortcuts.
We factor in user engagement
when scheduling these background
tasks and glances count as
engagement.
If you have an intent-based
shortcut, your intent might
update applications when it
executes in the background.
Since the intents extension is
in a separate process from your
Watch Kit extension, we're now
supplying a new refresh
background task called
WKIntentDidRun
RefreshBackgroundTask to let
your main extension run and
update any snapshots or
complications that may be stale
after your intent executed.
Now that you have your shortcuts
available at the turn of the
wrist and a tap, you should know
that users can set up shortcut
phrases on the phone and use
them to execute your shortcuts
at any time.
These shortcut phrases are
synced to Apple Watch.
So, you can use raise to speak
to say, for example, mint me up
and kick of an order of a mint
mojito from Phil's Coffee.
Your shortcut platter does not
need to be showing on the Siri
Watch face for your shortcuts to
be invoked with a shortcut
phrase.
So, in summary, use Siri
shortcuts to provide relevant
information and quick
interactions to your users.
Create relevant shortcuts on
both iPhone and Apple Watch and
add them to the shortcut store
so they can be considered for
the Siri Watch face.
And finally, your users will
have the best experience with a
WatchOS app where they'll be
able to do more with your
shortcuts directly on the Watch.
For more on Siri shortcuts, I
recommend checking out one of
these sessions or labs,
especially the one about Siri
shortcuts on the Siri Watch
face, which will go into much
more detail about the APIs I
covered today.
So, we covered a lot of ground
today.
Here's what we talked about.
We want you to make your
notifications more engaging and
actionable by creating dynamic
interactive interfaces for your
notifications.
You can now bring audio into the
background with AV foundation
APIs, media remote commands and
access to now playing info.
You can make your fitness apps
more robust and reliable with
the new workout builder API.
And you can provide value on the
Siri Watch face by creating
relevant shortcuts.
If you have any questions about
what you've heard today what you
built for Watch OS so far, or
what you're going to build next
come visit us in the labs.
We'd love to see what you're
working on.
Thank you for coming and have a
great WWDC.
[ Applause ]