I am developing a watchOS wellness app with explicitly user-started monitoring during ordinary daily activities. The goal is timely physiological-change check-ins over an approximately eight-to-ten-hour monitoring period, including when the display is off. This is not exercise monitoring or a diagnostic use case.
The relevant API sequence is:
- Create HKWorkoutConfiguration with activityType .mindAndBody and locationType .unknown.
- Create HKWorkoutSession, its associated HKLiveWorkoutBuilder and HKLiveWorkoutDataSource; set the session and builder delegates.
- Restrict builder collection to heart rate, then call startActivity(with:) and beginCollection(withStart:).
- After receiving initial live HR, call HKWorkoutSession.pause().
- Receive .heartRate through workoutBuilder(_:didCollectDataOf:) and read statistics(for:), mostRecentQuantity() and mostRecentQuantityDateInterval().
- When the user ends monitoring, end collection and discard the workout rather than save it.
In development tests on Apple Watch hardware, HR callbacks have continued for hours after pausing, including while backgrounded, with roughly five-second average intervals. Some tests have shown gaps. I do not assume that observing this behavior establishes a supported API guarantee.
Is frequent live-builder HR delivery in the paused state officially supported, or is this behavior an implementation detail that an app must not rely on? Is there a supported watchOS API or architecture for this non-exercise monitoring goal, and what are its HR-delivery/background-runtime limits?
The app uses HealthKit and HealthKit background-delivery entitlements and the workout-processing background mode. I would also appreciate clarification about possible Activity-ring or energy-calculation effects when the workout is paused and ultimately discarded.I am developing a watchOS wellness app with explicitly user-started monitoring during ordinary daily activities. The goal is timely physiological-change check-ins over an approximately eight-to-ten-hour monitoring period, including when the display is off. This is not exercise monitoring or a diagnostic use case.
The relevant API sequence is:
- Create HKWorkoutConfiguration with activityType .mindAndBody and locationType .unknown.
- Create HKWorkoutSession, its associated HKLiveWorkoutBuilder and HKLiveWorkoutDataSource; set the session and builder delegates.
- Restrict builder collection to heart rate, then call startActivity(with:) and beginCollection(withStart:).
- After receiving initial live HR, call HKWorkoutSession.pause().
- Receive .heartRate through workoutBuilder(_:didCollectDataOf:) and read statistics(for:), mostRecentQuantity() and mostRecentQuantityDateInterval().
- When the user ends monitoring, end collection and discard the workout rather than save it.
In development tests on Apple Watch hardware, HR callbacks have continued for hours after pausing, including while backgrounded, with roughly five-second average intervals. Some tests have shown gaps. I do not assume that observing this behavior establishes a supported API guarantee.
Is frequent live-builder HR delivery in the paused state officially supported, or is this behavior an implementation detail that an app must not rely on? Is there a supported watchOS API or architecture for this non-exercise monitoring goal, and what are its HR-delivery/background-runtime limits?
The app uses HealthKit and HealthKit background-delivery entitlements and the workout-processing background mode. I would also appreciate clarification about possible Activity-ring or energy-calculation effects when the workout is paused and ultimately discarded.