@Vision Pro Engineer @drewolbrich Thank you for filing this bug report. This is helpful. At this time I don't have a workaround to address the unwanted cutout effect issue. Thank you for responding. Separately from this specific issue, I'd like to understand how RealityKit determines draw order between (not within) model sort groups, and between view attachments and scene geometry. (I'm aware ModelSortGroup's order parameter controls ordering within a group.) I can't find this documented anywhere. How do you recommend I go about getting this question answered? I've already submitted a bug report, a code-level support request, and posted to the developer forums.

Hi @Vision Pro Engineer I've created a sample app and attached it to FB22014370. The sample app contains a README file with repro steps and a description of the issue. I initially created a simpler sample app, and in that app, the issue could actually be fixed using breakthroughEffect as you suggested. (Incidentally, breakthroughEffect does not appear to fix the issue in the simulator.) However, in the actual app I'm working on, breakthroughEffect surprisingly did not solve the problem, and the cutout effect was still visible in that app. Through trial and error, I discovered that breakthroughEffect does not appear to help for scenes that use ModelSortGroupComponent and which also contain more than one ModelEntity with ModelSortGroupComponent assigned, and for which view attachments are positioned beyond the center point of the bounding box of model entities with the shared ModelSortGroup, from the perspective of the camera. This scenario is demonstrated in the sample app. In the sample app's README file, I've also included specific questions about the behavior of transparent view attachments when used with scenes that use ModelSortGroupComponent. I tried your OpacityComponent suggestion and the view attachment draw order I observed was the same as when I used the opacity view modifier. I appreciate any assistance you can provide to help address the unwanted cutout effect issue.

I was able to fix the issue this way: sqlite3 ~/Library/Application\ Support/com.apple.TCC/TCC.db \ "DELETE FROM access WHERE client = '/Users/drew/Library/Developer/Xcode/CodingAssistant/Agents/Versions/26.3/claude'" (anyone else trying this will have to change the user name in the string) and then sudo killall tccd and then restarting Xcode.

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.