I have found the following to work: from your phone, remove the watch app by toggling the "show on watch". If you have a watch only app, delete the app from the watch. That's it, you should now be able to install and launch the watch app from Xcode.

I'm not sure if you are using it for open water swimming, but it may be related to an issue that I have described in detail here: https://developer.apple.com/forums/thread/737819

I just posted this: https://developer.apple.com/forums/thread/737819 Yes, during Open Water Swims, GPS performance on the ULTRA has degraded severely. We have several users now reporting that the GPS tracks produced during Open water workouts with either built in Workout OR with Open Water Swim are now largely unusable. I have confirmed this with my own swims as well. I would appreciate an upvote on my post as well. BTW, the issue is identical for the built in Workout app during open water swim.

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

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

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.

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).

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.

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

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.

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

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

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

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.

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?