Well I tried both styles. The initial code was the swiftui .backgroundTask modifier which worked in iOS 18. I created a core data based logger to see where the hiccup was. I noticed data was indeed being read by the anchored queries from HealthKit. That data was then sent to a couple of published properties in observable objects which served as the start of the combine pipelines. In ios18 that led to updates that were critical for updating widgets. In iOS 26, the combine pipelines were not activated. So I switched back to the previous method of background tasks, ie wkapplication.scheduleBackgroundRefresh(...) That also did not allow any combine pipelines to happen. In the end, I had to rip out combine from the watch and use didSet and custom handler blocks. While that did work, obviously it's not as full featured (ie, you can't debounce). After using blocks, things went back to functioning properly. Thoughts?

I actually moved back to the older handle () function on the app delegate as the .backgroundTask (swiftui) modifier didn't seem to be called at all. That said I'm dealing with a lack of combine pipeline in background tasks.

I resolved this issue, either via a restart or a re-install. I am now looking at combine pipelines in the background.

I am having an issue on watchOS 26 where HealthKit data does not appear to be able to be read while the app is in the background. When you do get an observer query triggering, are you able to read the data you need?

Having just moved from the previous method to the "new and improved" view modifier method, I have to say I am little less than impressed with Apple on this. We have an engineer on this thread. Where is the hold up? Are we supposed to spend time undoing the work we did? How does this reflect on "new and improved" features going forward.

Upon isolation of the issue, I don't believe it's a health kit reading issue that I'm encountering.

Did you figure out what was going on? I have a recurrent issue with HKAnchoredQueryDescriptor and HeartRate Samples and I think perhaps its related?

Also happening here. I use .backgroundTask modifier on WindowGroup. Only an issue with 18.4.

I was able to fix this by making sure all my targets, including test targets had exactly the same minimum deployment target. I had updated a couple of the targets to iOS 17 and left the test targets as they were.

Fixed is a stretch. Intent based widgets are causing major battery drain in release 10.5. But hey, thanks for the pride flag.

My feeling is that this is related to Intent Based Widgets. We could test this by removing all widgets from the watch face and seeing if there's an improvement since many widgets are now Intent based. There's a bug.

I'm getting warnings about missing NSPrivacyAccessedAPICategoryUserDefaults reason in the app extensions despite the main app having the correct reason in its privacy manifest (and getting no warning about the app missing that reason).

I am having the same issue with my app on 10.0.1. Open Water Swim. I only noticed it upon deleting and re-installing the app. If I perform clLocationManager.requestWhenInUseAuthorization() I get a big fat nothing. I will look into that crazy reset procedure and also file a bug report. This is the second bug relating to Core Location. There is also a serious degradation of GPS data (at least on the Ultra). I filed two bugs for this, one in beta FB12587468 and the newer one in release FB13192409. I would say Apple has really introduced some serious issues with core location on this release, and I would not be surprised if some folks end up losing jobs. Good riddance.

Did you get feedback from anyone on the dev team about this issue?

I am including three example data points that show there is an issue. These are locations that are mathematically impossible because the accuracies provided by the CoreLocation are less than the distances apart. These are CSV files each with two locations separated by a distance greater than the sum of provided accuracies. Typically one second apart (we allow 1 meter per second error) text-FC597A06C33E-1.txt text-4EAA0C645F55-1.txt text-F8A0F1CB22DE-1.txt