I have the answer here I think. No, not only does the Watch have to be running WatchOS 27, it also needs to be paired to an iPhone with Apple Intelligence enabled. This is despite the fact that PCC queries from WatchOS 27 go straight to the server and don't require the paired iPhone at all 🤷‍♂️

Hi lliyanke! No, I put that feedback in Nov 18, 2025, it was like putting a message in a bottle and throwing it in the ocean.....😯 So yes, never heard anything which is odd given Snippets were new. I'm still seeing the issue in iOS 27, although I haven't rebuilt the app with the new SDK incase that could help...

I had this issue, I could only use Device Hub with my own devices, no simulator would appear and I couldn't "see" my app when running it on a simulator even though there was console output. The fix for me was rebooting my Mac so I presume it's a bug. Fingers crossed this works for you!

ECGs have dedicated sample data when using the simulator and the Apple Health app. Something similar for this and a few other key types like Heart Rate Notifications would be very useful.

The layout of the Search/Browse tab is much improved 👏

Sorry, I‘ve not been clear enough with the question, I’m trying to determine if the device is viewing the Health data via synchronised iCloud or directly on device. The reason being the data via iCloud is often is delayed and so I’m trying to ensure I can provide the right experience to the user and set expectations. My app displays Apple Watch Health data and generally the paired iPhone‘s Health data stays right up to date with Apple Watch, but this isn’t the case for the iPad that also accesses the same data via iCloud. It’s not explicitly clear, but this delay issue might be something that is improved with the new 27 releases?

Is there any documentation or guides anywhere to indicate the duration/type/intensity of workout required to generate these VO2Max and Cardio Recovery values?

@DTS Engineer Any updates on this given the recent updates with WatchOS 27? That being said, a lot of my users will be staying on WatchOS 26 so I'm really still looking for a fix there as well! 🤞

Any new updates on this @DTS Engineer ? I did add the details to the feedback but no update so far. Thank you

Thank you very much for following this up. I can confirm this issue is still occuring and I've updated the feedback with new steps, sample code, sysdiagnose and crash report. Very much hope this helps get this replicated and resolved. Please do follow up when you can. Thank you

Any new updates on this @DTS Engineer Thank you!

These crashes are essentially what I'm still seeing in WatchOS 26.4 here

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.