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.