WWDC2019 Session 251

Transcript

[ Music ]
>> Hi, my name is Forest, and
I'm excited to talk to you about
new ways for apps to get runtime
on Apple Watch.
We'll review some of the
existing background modes as
well as the details of a new API
we've added in watchOS 6 to
enable more kinds of apps to get
extended runtime.
Brief interactions are what make
Apple Watch powerful.
You might raise your wrist to
check the time, the temperature,
your calendar or other
information that's clearly
visible on the watch face via
complication.
You might check a notification
from a language learning app.
Beyond that you might launch an
app to track a package, complete
a task or log a meal.
When you lower your wrist after
one of these activities, the app
becomes inactive.
After a short duration the
process is suspended but will
remain frontmost for some time
after meaning that it will
become active if you raise your
wrist during that time.
There are some use cases,
however, where you expect an app
to keep running after you lower
your wrist.
If you start a workout, you
expect Apple Watch to track the
time you've invested in that
workout and you might expect
other data to be collected as
well such as your current heart
rate, distance traveled,
elevation gained, steps per
minute and more.
As a developer, you can create
an app that tracks workouts
using the work API and
HealthKit.
Another obvious reason for an
app to continue running after
you lower your wrist is to play
audio via a connected Bluetooth
device.
You can start an audio session
by calling the background audio
APIs and in watchOS 6 you can
not only play local audio you
can also stream music, podcasts,
sporting events and more.
And, of course when you're
navigating, you need turn by
turn directions to be guided to
your next destination.
If you're building an app that
provides directions, you can
create a navigation session by
using core location APIs.
As we've built APIs around these
background modes over the past
few releases of watchOS, we've
noticed that some apps have
needs for additional runtime but
don't fall into any existing use
cases.
So now I'd like to hand this
over to Scott Daner to discuss a
new API in watchOS 6, which will
add support for new use cases.
>> Hi, I'm Scott Daner, and I'll
be walking you through the new
extended runtime API.
In watchOS 6, we're enabling new
scenarios through the extended
runtime API.
This API will provide enough
runtime to complete targeted
tasks even after the user lowers
a wrist while preserving
battery.
The extended runtime API
encompasses 5 use cases; self
care, mindfulness, physical
therapy, alarms and health
monitoring.
Each of these use cases has a
corresponding session type.
We've tailored these use cases
to meet the needs of each use
case.
This API is for scenarios that
are not workouts and, thus,
should not impact move and
exercise rings and while some
apps may benefit from monitoring
and reporting on the user's
heart rate, none of the session
types we're about to talk about
have heart rate monitoring on by
default as workouts do.
We'll go into this in more
detail in a bit but monitoring
user's heart rate is power
intensive so queries for heart
rate should be performed
judiciously.
The first session type we'll
talk about is self care.
Self care apps guide users
through brief activities focused
on the user's health such as
tooth brushing.
A self care session runs for up
to 10 minutes or until the user
exits the app by pressing the
digital crown or switching to
another app.
If the user lowers their wrist,
the screen will turn off, but
the session will continue
running and your process will
not be suspended.
This allows the app to play
sounds and haptics or
communicate with a Bluetooth
device.
Mindfulness apps guide users
through meditation sessions.
Some mindfulness apps are
already getting the runtime they
need by playing audio
continuously throughout the
session and that's fine.
The background audio API can be
used for those scenarios.
This use case provides runtime
for meditations where audio is
not played continuously.
Like self care sessions,
mindfulness sessions run until
the user exits the app or the
time limit expires.
For mindfulness sessions the
time limit is 1 hour.
Physical therapy apps guide
users through stretching,
strengthening or range of motion
exercises.
Physical therapy sessions are
designed to give you the runtime
you need to play haptics to
alert the user when it's time to
switch legs, change rotation
direction, et cetera.
These sessions continue to run
in the background if the user
presses the digital crown or
switches to another app to allow
for multitasking when doing
repetitive movements.
This is similar to how workout
sessions behave.
There's a one 1-time limit, but
you should end the session as
soon as the user has finished
the routine.
Remember that physical therapy
sessions are designed
specifically for activities that
are not workouts.
If your physical therapy app
offers a more strenuous activity
such as riding an exercise bike,
use a workout API for that
activity.
Health monitoring apps get
runtime to monitor the user's
health data such as heart rate
or motion.
Just like today the app must
query for heart rate through
HealthKit APIs.
This will turn on the heart rate
sensor, which will have an
impact on battery life, so
communicating that to your user
is critical.
Because of the potential for
heavy battery impact this type
requires an entitlement and
you'll need to be extra
respectful of the user's
battery.
In order to use this API, you'll
need to add the background modes
capability to your extension
target in Xcode and select an
appropriate session type.
To create a session first create
a WKExtendedRuntimeSession
object.
This will create a session, but
it won't start it yet.
To do that you must set a
delegate on the session and call
start.
Calling start must be done while
the app is active.
After calling start the session
will start immediately and you
will receive a call back noting
that it began successfully.
Finally, you can end the session
by calling invalidate.
And now to talk about alarms I'd
like to bring Forest back.
>> In most cases if an app needs
to alert a user at a specific
time, the best way to do this is
through a notification.
However, there are cases where a
notification is not sufficient
such as waking the user from
sleep.
In this case, the app might want
to get runtime to monitor the
user's heart rate or motion to
determine an optimal time to
play an alarm.
To enable this, we've added the
alarm session type.
Smart alarm sessions allow apps
to schedule a window in which to
begin monitoring for changes in
heart rate or movement.
Alarm sessions are the only type
of session that can be scheduled
in advance up to 36 hours and
can run for up to 30 minutes
once started.
You must play a haptic at least
one time during the course of
the session as your purpose is
to act as an alarm.
If your application is using the
alarm session type, there's one
key difference about how the
session works.
These sessions are scheduled in
advance.
To schedule an alarm session
instead of calling start, call
startAtDate.
This will schedule the alarm to
begin running at a later date.
Also, just as you must call
start when the application is
active startAtDate must also be
called while active.
Later at the time specified the
session will begin and the app
will be launched if it's not
running.
Upon launching the app will
receive a call back on the
extension delegate which passes
the app the running session.
The app must set a delegate on
the session before returning
from this function.
After doing this the app will
receive a call back on the
delegate object saying that the
session has started.
During the time the session is
actively running the app must
play a haptic.
When your app plays a haptic
during an alarm session if it is
not active, we will show a
system alert indicating that
your app is playing alarm.
If your app fails to play a
haptic during an alarm session,
we will warn the user with this
alert offering to disable the
app's ability to schedule
sessions in the future.
Make sure you're being a good
citizen on the platform.
If you are, your users will
never see this.
We've put a lot of thought into
the parameters of these use
cases.
So please pick a use case that's
appropriate for your app.
Be considerate of the user's
battery life.
End sessions as soon as the user
is done with the activity and be
judicious about querying heart
rate.
This will ensure great battery
life for your users.
For more information, check out
the documentation
@developer.apple.com.