So just to clear up, the full steps are: Connect to same wifi network On Vision Pro -> Settings > General > Remote Devices On Mac -> Xcode -> Devices & Simulators -> Select the Vision Pro & enter the code On Mac -> Run a build targeted at your vision pro device which should now be a run destination (Developer mode setting wasn't visible till I did this), you will get an error saying developer mode is not enabled On Vision Pro -> Privacy & Security > Developer Mode Quite a process, surprised someone forgot to document this :)

@Frameworks Engineer Thanks for the reply - it seems my Mac/Xcode were just having some issues that day fixed by rebooting. What was happing was this iPhone stub target wasn't getting created, but on the test project I created today, it is working again. The app also was given a bundle identifier of .watchkitapp without appending the co.swiftfox.AppName, so it seems like somehow I was passing an empty app name string into the creation dialog. I ended up just building an iPhone version of the watch app in question, so it worked out.

So small update - I made a test app using Xcode 15 RC, my same location service used in the main app and a simple UI to request location and display it + any errors on both the phone and the watch. And...everything works fine. My guess is prior Xcode beta versions had some build configuration issue set on the target, so I'm going to make a branch, delete my existing apple watch app target, and recreate a new one on the RC and see if that works.

I'm also seeing the same, now on the RC build. This is on a new app and my first time developing for watchOS, so I thought it was just something I was doing wrong - but after trying it out on a watchOS 9 watch - everything works perfectly fine. On watchOS 10 RC + built with Xcode 15 RC my app gets authorizedWhenInUse when I call CLLocationManager.authorizationStatus, so I then proceed to request location, where I then get denied with Error Domain=kCLErrorDomain Code=1 "(null)" I've even tried using the new way to fetch location using async/await (CLLocationUpdate.liveUpdates()), but seems to be the same issue, just in that case the task never completes or fails, I just never get a location. iOS app works fine on iOS 16/17. Watch app works on watchOS 9. Anyone find any workarounds? I was excited to launch my first watchOS app at the watchOS 10 launch, but this bug has put a damper on things, and my app doesn't really work without current location. And I can't build with prior Xcode versions as I'm using watchOS 10 specific features...

Unfortunately still happening in Beta 6. Anyone find any other workarounds? I submitted a radar (FB11367854) using the following example. Sucks because I doubt it is going to be fixed before the RC xcode 14 release, hopefully it can get into 14.1. Looks like I may have to my change design or not support iOS 16 features for now. import SwiftUI enum Setting: String, CaseIterable {     case first = "First"     case second = "Second"     case third = "Third" } struct ContentView: View {     @State var setting: Setting = .first     var body: some View {         NavigationView {             VStack {                 Text("Setting: \(setting.rawValue)")                 /// Picker works when in a normal view                 Picker("Change Setting", selection: $setting) {                     ForEach(Setting.allCases, id: \.self) { setting in                         Text(setting.rawValue).tag(setting)                     }                 }             }             .padding()             .navigationTitle("ToolbarBug")             .toolbar {                 ToolbarItem {                     Menu("Test") {                         // This display of the setting also never changes                         Text("Current setting: \(setting.rawValue)")                         // Picker within a toolbar item does not update it's selection checkmark                         Picker("Change Setting", selection: $setting) {                             ForEach(Setting.allCases, id: \.self) { setting in                                 Text(setting.rawValue).tag(setting)                             }                         }                     }                 }             }         }     } } struct ContentView_Previews: PreviewProvider {     static var previews: some View {         ContentView()     } }

I'm seeing this as well from my app. It seems to only happen 5% of the time, but more often when I am changing widget configurations and asking for a reload, then it will trigger repeated flashing. I find that it immediately stops if I force quit the "container" app...I'm not sure if this also kills off any widget extension processes? It is super annoying as when it happens the debugger will disconnect. I also tried viewing console logs, but it seems they also stop when the flashing begins. So I'm at a loss as to whether this is a WidgetKit bug or a bug in my widget.