Create an extended runtime session that continues running your app after the user stops interacting with it.
An app running on Apple Watch normally transitions to the background and becomes suspended when the user lowers their wrist. However, your app can use both background sessions and extended runtime sessions to continue running after the user stops interacting with it.
With background sessions, your app continues to run in the background, but the sessions can only be used for monitoring workouts, location tracking, or playing audio files. Extended runtime sessions, on the other hand, expand on this ability and give your app a number of different session types to choose from, although not all of the sessions run in the background. Some keep your app active and running as the frontmost app instead. Extended runtime sessions support the following session types:
- Self care
Guide users through relatively brief activities. These activities focus on the user’s emotional well-being or health, such as brushing their teeth.
Help users start and end silent meditation sessions. For walking meditation, consider using
HKWorkoutinstead. Similarly, if your app plays audio during the entire meditation session, there’s no reason to use a
WKExtended. The background audio mode provides additional runtime as long as the audio plays. For more information, see Playing Background Audio.
- Physical therapy
Guide users through stretching, strengthening, or range-of-motion exercises. If the physical therapy activity is strenuous—for example, riding an exercise bike—consider using an
- Smart alarm
Schedule a window of time to monitor the user’s heart rate and motion. The app uses this information to determine the optimal time to play an alarm, usually to wake the user from sleep.
- Health monitoring
Monitor the user’s health using the watch’s heart rate or motion sensors. During a health monitoring session, you can access health data with HealthKit APIs like the
HKAnchored. If you query for heart rate data, the watch turns on the heart rate sensor. Health monitoring sessions—especially ones that use the heart rate sensor—can have a significant impact on battery life. Make sure to communicate this impact to your users. You must also request a special entitlement to enable these sessions.
Select a session type based on the app’s intended use—not based on the features that the session provides. Extended runtime sessions let the app continue to communicate with a Bluetooth device, process data, or play sounds or haptics, even after the watch’s screen turns off.
Set Up the Session
Before starting an extended runtime session, enable your WatchKit extension’s Background Modes capability. For most sessions, you also select your app’s session type (see Figure 1); however, for health monitoring, you must request a special entitlement to enable the session.
Each app can only support one type of extended runtime session, although it’s possible to support other background modes in combination with extended runtime.
A physical therapy app, for example, might use a
WKExtended for range-of-motion exercises and an
HKWorkout for vigorous cross-training. Using separate sessions keeps the range-of-motion exercise from impacting the user’s Move and Exercise rings, but the user still gets full credit for the cross-training.
To set up the session, instantiate a
WKExtended object, and assign your delegate. The system automatically creates a session based on the session type specified in your Background Modes capabilities.
WKExtended methods to track your session.
Finally, start your session. For most session types, you start the session immediately by calling
start(). For alarm sessions, you can schedule the session to start any time within the next 36 hours by calling
You must always start or schedule the extended runtime session when your app state is in the
For sessions started with
start(at:), you can only call
invalidate() when the app is active. For all other sessions, you can call
invalidate() to end a session at any time.
Understand Session Behaviors
Extended runtime sessions gain the following features, based on the session type.
Frontmost sessions continue to run in the foreground. The watch screen doesn’t need to remain on to keep your app alive. The session continues until the time limit expires, your app invalidates the session, or the user explicitly leaves your app (for example, by pressing the digital crown or switching to a different app).
Background sessions continue to run in the background, even if the user dismisses the app or launches another app. Background sessions continue to run until the time limit expires, or your app invalidates the session.
Finally, schedulable sessions can start any time within the next 36 hours. You must schedule the session by calling
start(at:) while your app is in the
WKApplication state. The system can then suspend or terminate your app without affecting the session. The system relaunches your app as needed to handle a scheduled session, calling your extension delegate’s
handle(_:) method. If you don’t set the session’s delegate in the
handle(_:) method, the system ends the session. Additionally, you can only schedule one session at a time; if you need to reschedule a session, invalidate the current session, and schedule a new one.
After the session starts, the app continues to run in the background until the time limit expires, or your app invalidates the session. During the session, your app must trigger the alarm by calling the session’s
notify method. If your app isn’t active, playing the haptic displays a system alarm alert to the user.
If you fail to play a haptic during the session, the system displays a warning and offers to disable future sessions.