Hi Ziqiao, Sorry for the slow response, I've been trying to do some more testing before responding... I think I was getting confused in some instances between WKApplicationDelegateAdaptor and WKExtensionDelegateAdaptor. This is a modern single target app so yes I should be using the former. And thank you on the tech note, really useful for clarity on the confusing! I am now finding that with the @WKApplicationDelegateAdaptor route I can implement the func handle(_ backgroundTasks: Set<WKRefreshBackgroundTask>) {} method and there do work and schedule the next update. With a widget/complication on the watch face I get update calls variably between every 15-90 minutes despite requesting an update every 15 minutes. This is running the latest WatchOS 26.3, I appreciate there are lots of constraints on this which are hard to debug, but despite that I would have expected slightly more updates to get closer to the "4 per hour" target. Removing the complication from the watch face seems to take the update number to never, again I though the occasional update might have been called. The crashes continue to roll in on my iPhone in the Analytics data section for this test app. Every few minutes I still get a CSLHandleBackgroundHealthKitQueryAction watchdog transgression despite having removed the HealthKit background observer code and the .enableBackgroundDelivery(for: HKQuantityType(.heartRate),frequency: .immediate) entry. I presume there's no way to .disableBackgroundDelivery()? Is there anything else you need me to do here or try relating to FB22115840? To clarify my previous statement about being able to "use the HealthKit background observer query to receive heart rate data once per hour with or without a complication on the watch face", I more mean that the crashes continue to occur regardless of a complication on the watch face or not. The feedback did receive a reply mentioning DispatchQueue.main.async use and maybe an issue with completing a task too early? It was a little confusing, but in any case I’d tested without using the DispatchQueue.main.async so there’s still a problem here. Many thanks

Hi Ziqiao, An update here on this. Using the sample app I added to the feedback FB22115840 I have confirmed I can use the HealthKit background observer query to receive heart rate data once per hour with or without a complication on the watch face. This was running WatchOS 26.3. The crashes continue to occur with the watchdog terminations (as it does with my actual published app) so that needs to be addressed unless I am configuring it wrong in the sample project. Related to this is still that clarity on if I need to implement @WKExtensionDelegateAdaptor Then there's the "4 updates per hour" with a complication on the active Watch face.... are these updates just referring to updates to your WidgetKit timeline (if using WidgetKit) and not actual background updates in your Watch app like you used to get with ClockKit? Or is not, do we have to schedule these updates like exampled here? Back to the original query of the post, does the "health monitoring entitlement" still exist? Thank you

Ok, thank you Ziqiao for the detailed & quick response, most appreciated. Folks who are exploring how to achieve that goal might consider shifting the direction. I agree... I just hope we can either clarify better alternative for those apps, or if not available, provide input to future APIs. In that case, I can ony suggest that yo file a feedback report, as mentioned in the post. If you already have one, please share so I can check the status. I see folks reporting this issue from time to time, but haven't yet seen them sharing their report. I have filed a feedback FB22115840 and created a sample project and provided a crash report. I think all the code is correct in terms of calling of completionHandler() and I've tried to simplify the project🤞🤞 really hope this is useful as would love to see a fix soon. The SwiftUI equivalent is backgroundTask(_:action:). I read the guidance but I still struggle to understand if on WatchOS, when using that API, you can avoid using a @WKExtensionDelegateAdaptor Having a complication on the active watch face adds the priority of the app, and impacts the execution time allocation policy on the system side, no matter the complication is based on ClockKit or WidgetKit. The difference I'm trying to highlight here is (AFAIK) that older ClockKit APIs wake your WatchOS app, WidgetKit reloads wake your WidgetExtension where you can do less from (no WatchConnectivity, no local notifications etc...), making this a regression. Yes. I am not quite sure if we document "1 update an hour" though. I got this from here. It's confusing because it says other than certain metrics you're limited to hourly, but then it mentions the bit you covered "Also, in watchOS, the background updates share a budget with WKApplicationRefreshBackgroundTask tasks. Your app can receive four updates (or background app refresh tasks) an hour, as long as it has a complication on the active watch face." So which is it I wonder.... I don't think the WidgetKit complication timeline refresh is counted to the budget of the app's background execution time. Ok, so having a complication on the watch face implemented with WidgetKit gives you what ever reload allowance it gives you in the WidgetKit timeline, plus, totally separately you get up to 4 background refreshes per hour in your Watch App which would apply to the HealthKit HKObserver? Thank you very much for all the help here, the thing I'm still trying to get to here is can my WatchOS app (not widget extension) get access to 4 updates per hour reliably.

Thank you for the response. Unfortunately as this isn't for a research app SensorKit is probably Out. There seems to be a lot of developers all trying to achieve similar things and running into various problems around background access to HealthKit data on WatchOS. This post discusses using a Workout session to maintain background access. This is a very poor user experience as far as battery life goes but many apps are resorting to it for lack of better alternative. This post discusses getting crashes on WatchOS 26 for exhausting CPU time with background HKObserverQueries, I too am seeing this despite calling the completion handler immediately and not running any processing code, is there any solution? Related to the scenario in point 2, are we also required to implement @WKExtensionDelegateAdaptor(ExtensionDelegate.self) var extensionDelegate and call tasks completed or is the completion handler in the observer sufficient? func handle(_ backgroundTasks: Set<WKRefreshBackgroundTask>) { for task in backgroundTasks { task.setTaskCompletedWithSnapshot(false) } } In various places such as here I see discussion about if the app has a complication on the watch face and as such, it gets 4 updates an hour. This I find confusing... Pre-WatchOS 9 with ClockKit complications this makes sense, but since migrating to WidgetKit, I now get my widget extension woken for timeline updates and not my app. This is fine but not helpful for my use case and so has caused a regression in my app as I no longer get Watch app background updates from this... I hope I've made the differences clear here? Related to previous point, my understanding with this code try await healthStore.enableBackgroundDelivery(for: HKQuantityType(.heartRate),frequency: .immediate) is that although I ask for immediate, I'll be limited to 1 update an hour for heart rate on WatchOS, do I still get that update if I don't have a complication on the Watch face? If I do have a complication on the active watch face, does that update have any impact on my complication WidgetKit timeline refreshes? Overall I think there is a lot of confusion in the developer community with this topic and if not before, hopefully in the next cycle this is either all cleared up or even better some new slightly less restrictive APIs arrive. To answer your question for me, my use case is wanting to review health data that the watch already automatically records (I don't want to trigger battery intensive additional sampling) and then with provide notifications or other features to the user from that. These updates could probably be done in a second of CPU time if only I could reliably access it...

Just seen this post. I feel given the detailed write up it's a shame no one's otherwise picked it up with at least some response. Ultimately I think there's no solution here with the current APIs. There are background observer HealthKit APIs for HR data but they don't work to your requirements and potentially with WatchOS 26 they don't work well at all! (see here) I wasn't aware of the entitlement you mention for Health Monitoring, it caused me to write this post. One other "solution" I'm aware of if your app includes a complication on the watch face -> If you use the legacy ClockKit APIs rather than the newer WidgetKit ones to create this complication, you'll get app waking calls to update this. If you've migrated to WidgetKit this only wakes up the Widget extension which is not so useful. This will still likely not give you the frequency you require. Beyond that I think it's still a waiting game for better APIs.

@DTS Engineer Thanks for the suggestion, sorry I should have mentioned I tried that. Unfortunately doing this puts the safeAreaBar content in the wrong place, overlaid on the whole view rather than the scrollview. Hopefully the screenshot demonstrates this. I've now filed a feedback for this FB21613303. I didn't put the feedback in originally because I've submitted 3 in the past 3 months all with sample code, details etc... and not even had an acknowledgement ☹️ But if you say they help, I will keep submitting! Thanks

@DTS Engineer this is helpful thank you. Are you able to verify that doing this does not breach App Review or other terms as seemingly it's bypassing the same restrictions Apple has themselves had to implement? Finally this does result in a poor user experience: I don't know which user's Watches are affected, there's no API to query this? It's not actually region specific. Does the HealthKit source differ maybe such that I can observe that? A separate syncing system is inefficient, less likely to be accurate and has all the limitations mentioned previously re. access to iPhone Health Store when device is locked I presume there's not much to add on these points so I'll file a feedback but I do think this is confusing/misleading for users who otherwise presumably expect the SPO2 data to behave like any other.

Going back to my original questions I think I have some answers forming: Yes, SPO2 values are saved to Apple Health on iPhone Yes, background measurements are now taken in the same way Yes, the data is visible through the HealthKit APIs on iPhone only - not directly on Apple Watch No, HealthKit does not sync these values back to the Apple Watch Health Store Does this mean I'd have to use frameworks like WatchConnectivity to pass SPO2 data back to my Watch app? Am I allowed to do that as seemingly Apple Health isn't? Is there a better approach given the user's iPhone is most likely locked when using their Apple Watch and so the Health store on iPhone is unavailable?

I think you'll struggle here. As I understand it the iPhone is generally locked when in use with CarPlay. If the iPhone is locked, access to the Health Store database is unavailable. This would mean you couldn't access those blood glucose values.

Ok done, FB20278031 Anything that can be done to boost the feedback is very appreciated 🙏

I second this query. As the developer of a Heart Rate app, it's particularly frustrating the the Heart Rate section of the Apple Health app offers step trackers and yoga classes which don't or barely show HR data to their users.

Any updates on this? @DTS Engineer Thanks

For any unfortunate peoples stumbling across this, the issue was not solved in the RC builds of iOS & WatchOS 26. I'm shipping anyway and have had to build in a knowledge base in the app to help users with missing complications. 😞 Not the outcome I wanted and will undoubtedly lead to a lot of emails and negative reviews..... But I have users who expect the latest features so what else can I do.....

I'm also seeing this problem with Swift Charts. This is with the latest Xcode 26 Beta 6 and iOS 26 Beta 8. This issue doesn't affect devices running iOS 18 and 17 from my testing. As such I've made this modifier which may help someone, hopefully I can remove it in the release seed but who knows! extension View { func CustomTapGesture(tapCount:Int = 1, perform action: @escaping () -> Void ) -> some View { modifier(TapGestureModifier(tapCount: tapCount, action: action)) } } struct TapGestureModifier: ViewModifier { var tapCount:Int = 1 var action: (() -> Void) func body(content: Content) -> some View { if #available(iOS 26.0, *) { content.simultaneousGesture(TapGesture(count: tapCount).onEnded { action() }) } else { content.onTapGesture(count: tapCount) { action() } } } } Which can be used like this: Text("Hello World") .CustomTapGesture(tapCount:2) { UIImpactFeedbackGenerator().impactOccurred() } To be clear, this doesn't work as well for iOS 26 users as the standard .onTapGesture but it is a workaround.

Hi Ziqiao, Thank you for the response on this. All your first paragraph points sound good. Unfortunately I too don't have an affected device so short of importing one, I'm not sure on the exact behaviour. As for the measurements, yes any further details you can provide would be good including if the background measurements are still taken in the same way on these models and if data can be automatically synced back to iPhone and therefore the HealthKit database when the iPhone is available. Thank you