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.

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.