I was able to reproduce this issue in visionOS 26.2.

I believe I've discovered a workaround for this pushWindow bug. If I add the .restorationBehavior(.disabled) scene modifier to the WindowGroup corresponding to the pushed window, the bug doesn't happen. If the user pins a pushed window to the wall, the window doesn't disappear, and the app and all other apps that may call pushWindow aren't bricked until the next device reboot.

I believe I've discovered a workaround for this pushWindow bug. If I add the .restorationBehavior(.disabled) scene modifier to the WindowGroup corresponding to the pushed window, the bug doesn't happen. When dismissWindow is called on a pushed window, the parent window reappears in the expected location.

Thank you to everyone who posted suggestions and workarounds.

I was able to reproduce this bug using Xcode 26.0 beta 5 (17A5295f).

I was able to reproduce this bug using Xcode 26.0 beta 4 (17A5285i).

I encountered this same problem, but like @nevyn reported, the Xcode Cloud error referenced my RealityKit assets bundle as a whole, and not a skybox specifically. I discovered that the cause of the error was an ImageBasedLightComponent I had defined in my Reality Composer Pro project. My ImageBasedLightComponent was referencing a PNG file, not an HDR file. I still saw the error even after removing the PNG file reference entirely. I removed the ImageBasedLightComponent and created my ImageBasedLightComponent in code instead. After making that change, I was able to successfully deploy my app using Xcode Cloud, and I no longer saw the "realitytool requires Metal for this operation and it is not available in this build environment" error message.

I was able to reproduce this bug using Xcode 26.0 beta 3 (17A5276g).

I was able to reproduce this bug in 26.0 beta 2 (17A5241o).

FB18241928 includes a minimal sample app demonstrating the issue and detailed repro steps.

Workaround version that includes import SwiftUI:

As the engineer above wrote, the answer to this question is in the Xcode 26 release notes: Xcode may crash on launch restoring UI state. (152042209) Workaround: Remove your UserInterfaceState.xcuserstate file from the project/workspace. In macOS Terminal, you can find this file in your Xcode project directory tree with: find . -name '*.xcuserstate' -print and then delete it with rm. I have been assured that this is a cache file and contains no important project state and is safe to remove.

This issue appears to be fixed in Reality Composer Pro 2.0 (476.0.0.508.4), included with Xcode 26.0 beta (17A5241e).

(response continued from reply to the apple engineer in the accepted answer to work around the dev forum's 500 character comment limit) fwiw, the page https://developer.apple.com/documentation/realitykit/loading-entities-from-a-file describes .reality files in the context of the Reality Composer app (the old one), not Reality Composer Pro. Until you mentioned it just now, it wasn't clear to me that a RealityKitContent bundle contains a .realty file, as this implementation detail is not exposed in any user-facing way in Reality Composer Pro or Xcode. The page https://developer.apple.com/documentation/visionOS/designing-realitykit-content-with-reality-composer-pro does mention .reality files in two callouts that specifically refer to the their importance for performance reasons, but without deep investigation, this is confusing to a new user. I didn't notice that my project was using .reality files at all until just now when, motivated by your developer forums answer, I happened to look in /Users/drew/Library/Developer/CoreSimulator/Devices/A50E7AE3-EDE3-44BA-878B-E0DBE4A6F834/data/Containers/Bundle/Application/4C2EF75B-AE35-42B0-8A5B-ABE2B74CCE82/Baseball.app/RealityKitContent_RealityKitContent.bundle It would be nice if https://developer.apple.com/documentation/realitykit/loading-entities-from-a-file and the documentation for ModelEntity https://developer.apple.com/documentation/realitykit/modelentity and Entity(named:in:) https://developer.apple.com/documentation/realitykit/entity/init(named:in:) could be updated to make this clearer.

If you've implemented a workaround for this issue, you may want to investigate it again. I think it may have been fixed in iOS 18.5 or perhaps earlier.