User also has to enable System Settings > Privacy & Security > Sensitive Content Warning. Which makes this feature useless for me as I would like to use it as input (not output) filter. As I doubt that people posting di*k-pics will turn this warning on :)

This could happen if you added StoreKit configuration file and added it to Options of Run scheme: Get wrong receipt data from Apple - https://developer.apple.com/forums/thread/729543?answerId=752823022#752823022

The issue is unfortunately not fully solved with iOS 17 RC: Previous versions of the app which updated after installing RC doesn't have the issue Freshly installed versions of the app on RC doesn't have this issue As soon as app is deleted and installed again on RC - locations are broken

Also after you reset location permissions globally it starts to work. Till you delete and install the app again - then association is broken again. It might be that location permission even work in beta 6-8 if you just upgrade the app without deleting it at some moment. But for developer it's hard to trace.

@rsebbe @jclardy Good news everyone! It seems that if you install iOS 17 RC on device that never had pervious iOS 17 beta locations are received on the watch as expected! If you install on the watch simulator which you have not used with previous betas locations works there too. So I assume it should work in production as only minority of users would install your app on the beta iOS.

@WeatherGods Thanks a lot for sharing your solution! Meanwhile I have tried to create blank project with only phone and separate watch app and locations in the watch version worked for me. So I think single app per se should not be source of the problem. Unfortunately for me it's not so easy to switch back to watch extension as the change was done more than one year ago.

Also i wonder if i can get the GPS values like altimeter or location from the HKWorkoutSession? To gather these data you need CLLocation manager running along workout. When HKWorkoutSession is finished you create HKWorkout from it. And you could also create HKRoute from gathered locations (including altitudes) and associate it with HKWorkout https://developer.apple.com/documentation/healthkit/workouts_and_activity_rings/creating_a_workout_route

I forget to add that issue affects not only builds installed from Xcode or TestFlight, but also one from App Store.

I have the same problem since watchOS beta 7 When I debug code running on the watch I see that permissions are granted but CLLocationManager delivers no locations. Instead func locationManager(_ manager: CLLocationManager, didFailWithError error: Error) is called with message Error Domain=kCLErrorDomain Code=1 "(null)" - The operation couldn’t be completed. (kCLErrorDomain error 1.) BMLocationManager.swift locationManager(_:didFailWithError:) What doesn't help so far: Switching locations permissions off and on again Restarting the watch and phone Unpairing and pairing the watch Switching to Ask next time state (permissions dialog appeared on the phone but didn't help the watch)

For me it works after I ensure that watch, phone and laptop are connected to the same WiFi network. Also once it helped to plug USB cable from phone to different port of laptop.

Doesn't work for me as well. The error message is very general, it gives you no idea what could be wrong.

Maybe it's a different issue but form me migration of ClockKit complications to WidgetKit ones doesn't work. I can see that when I install new version of the app with WidgetKit complications none of the methods from ComplicationController are called, including func getWidgetConfiguration(from complicationDescriptor: CLKComplicationDescriptor,                completionHandler: @escaping (CLKComplicationWidgetMigrationConfiguration?) -> Void) which is necessary for migration.

This guy has figured out how to fix the issue: https://blog.nihongo-app.com/stop-xcode-14-beta-from-pegging-cpu/ TL;DR: copy wallpaper from iOS 15.5 simulator to iOS 16.0 one. mv /Applications/Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/Library/Wallpaper /Applications/Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/Library/Wallpaper-original && cp -r /Library/Developer/CoreSimulator/Profiles/Runtimes/iOS\ 15.5.simruntime/Contents/Resources/RuntimeRoot/Library/Wallpaper /Applications/Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/Library

Yes, I also experience this issue in the similar scenario. Never (or really rarely) happened on watchOS below 8. Come across as I'm looking for solution now.

The problem is connected with updating to Big Sur 11.3 The issue seems to be tied to having many libraries that are not part of the shared cache. That slows down dyld (it's shipped with the OS, not xcode) in unproportional way. I hope Apple will soon come up with the solution.