I don't claim to know what all the XML means but the change happens in my watch app schemes when I switch the selected device between the simulator and a real watch. When I select the simulator, BuildableProductRunnable is in effect but when I select a real watch, RemoteRunnable is in effect. It's almost as if the scheme has to change to allow remote debugging when using a real watch. So the state of the scheme files depends on the device selected when you last built in Xcode.

File > New > Editor Below

Here's the answer I received from Apple DTS. As for attribution, there is a REST API call for attribution, though looking at the documentation, I see it is not listed. I've already filed a request to have that added (r. 102144735). I encourage you to file your own feedback about this; feel free to reference the bug I filed when you do so. https://feedbackassistant.apple.com. The call is  https://weatherkit.apple.com/attribution/{locale} which returns JSON, with the attribution images and localized name for WeatherKit in that locale. For example https://weatherkit.apple.com/attribution/en-US returns  {     "logoDark@3x": "/assets/branding/en/Apple_Weather_wht_en_3X_090122.png",     "logoLight@1x": "/assets/branding/en/Apple_Weather_blk_en_1X_090122.png",     "logoDark@2x": "/assets/branding/en/Apple_Weather_wht_en_2X_090122.png",     "logoDark@1x": "/assets/branding/en/Apple_Weather_wht_en_1X_090122.png",     "logoLight@2x": "/assets/branding/en/Apple_Weather_blk_en_2X_090122.png",     "logoLight@3x": "/assets/branding/en/Apple_Weather_blk_en_3X_090122.png",     "logoSquare@2x": "/assets/branding/square-mark@2x.png",     "serviceName": "\uf8ff Weather",     "logoSquare@1x": "/assets/branding/square-mark.png",     "logoSquare@3x": "/assets/branding/square-mark@3x.png" }

I have the same problem. My watch app maintains a send queue of files to send to my iOS companion app. In watchOS 10.5, didFinishFileTransfer is never called. Hence my watch app never removes files from the queue and sends the same files repeatedly, even though the files do successfully make it to my iOS companion app. I just released a version of my iOS companion app that ignores transferred files it believes is have been previously received. I never needed to do that when didFinishFileTransfer was called. However, I wonder if I need to find a way to remove the files from my send queue. I could send a list of the files recently received from my iOS app back to my watch app so that my watch app could remove them from the queue. I'm going to wait and hope that Apple fixes this bug in a future release, in which case my watch app will send all the files again and my iOS app will ignore them. However, didFinishFileTransfer will be called and my watch app will remove the files from the queue. I did file a report with the Apple Feedback Assistant.

I filed two Feedback Assistant reports on Xcode 26 Beta 2. FB18441843 - Xcode 26 Beta 2 Linker Crash - Segmentation fault FB18442206 - Xcode 26 Beta 2 Linker Crash - Assertion failed: (it != _dylibToOrdinal.end()), function dylibToOrdinal, file OutputFile.cpp, line 5196 The first one uses the old linker (-ld64) and the second used the new linker. The -Xlinker -dead_strip -Xlinker -allow_dead_duplicates made no difference. I just hope the Xcode 26 Linker will link my app someday. Beta 1 and beta 2 were both abject failures.