Same issue here. Deleting the contents of ~/Library/Developer/Xcode/iOS DeviceSupport (also logs and caches) didn't solve the problem for me. With this configuration: Big Sur 11.3 Xcode 14.5 Simulator 14.5 my app start takes more than 30 seconds when running from xcode. Normal start of installed app takes 2 seconds. Xcode says "launching app", "attaching to app", and then "running app", at the running app stage I get a ~30 second pause. debugserver at 100% activity at that time. Unticking "Debug executable" makes start instantaneous but makes debugging impossible, it's not a solution. On the real device (running iOS 14.4) start with attached debugger takes around 6 seconds.

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.

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.

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

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.

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

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.

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)

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

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

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

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

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.

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

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