Can you try commenting out your entity/SpatialTapGesture code? I have a hunch that the entity may be intercepting taps intended for the button. visionOS has some odd issues when we place gestures on entities that the user will be inside of. You may want to take a look at SpatialEventGesture instead of using the tap in an entity. This will let you listen to input anywhere in the immersive space without using a specific entity. Docs: https://developer.apple.com/documentation/swiftui/spatialeventgesture Example Code: https://stepinto.vision/example-code/spatial-event-gesture/ Is .windowStyle(.plain) expected to affect button interaction behavior? No, I've used buttons in many plain windows. Unless visionOS 26.3 introduced a new bug, it seems like something else is going on here. What is the recommended approach to achieve a transparent/hidden window in immersive mode while maintaining button interactivity? You're on the right track, see above about the entity gesture intercepting input. Is there an alternative to .windowStyle(.plain) for hiding window chrome in visionOS? No, not for hiding the glass background of the a window. .plain window style is the only way.

There is a way to do this, but you will need to create a simple Shader Graph material instead of using the default OcclusionMaterial. There is a second version of this node called ShadowReceivingOcclusionSurface I didn't test this with Grounding Shadows, but it works with regular dynamic light shadows. You can find my notes on this from last year. https://stepinto.vision/labs/lab-026-using-dynamic-lights-and-shadows-with-passthrough/

So this isn't a good idea but it does work. If you load the immersive space as mixed style (instead of full or progressive), visionOS will not use that safety features. You can still occlude the users view using 3D content, skyboxes, etc. Just be aware that you may have to update your lighting, as visionOS will contribute passthrough lights into the scene. Like I said, it isn't a good idea. A friend added this to his app and while testing it I knocked over a lamp and walked into the wall a few times 😅

I was seeing the same thing, but it turns out I was looking in the wrong place. The USB section will always report 480MB, but when I check Thunderbolt/USB4 with a valid cable connected I get 20GB. Assuming your USB cable supports higher speeds, check this section and see what it says.

I downloaded this and added a few objects. The only thing that stands out to me is you use of ManipulationComponent.configureEntity(). In my opinion, you shouldn't be using that here. This sample already does the heavy lifting of creating collision and input target components. You are essentially overwriting those. Instead, try adding the component the "normal" way. let object = objectToPlace.materialize() let mc = ManipulationComponent() object.components.set(mc) A few other thoughts: This doesn't add the ManipulationComponent when restoring the scene. It only adds it when you are anchoring a new item, but not when respawning them. There may be some bugs or issues using ManipulationComponent along with ARKit. Since this is based on an existing sample, check the rest of the project for things that may be causing issues. I added around 30 items and never saw a crash or any errors.

@Vision Pro Engineer Thanks for looking at this. As requested, I uploaded an Xcode project and some new notes. This has a sphere with a default manipulation component, presented in a Volume. That's all it takes. I did some more testing with this today. Here is a breakdown if what I see: I put the headset on in room A and use manipulation. Works as intended. I physically walk to room B and try to use manipulation: TRANSLATION does not work. Once this breaks, it breaks across all apps. Restarting the device has been the only fix. It doesn't seem to matter how the volume is moved to Room B. All three of these provide the same result. Close the app in room A and open in room B Drag the app by the window bar to room B Render open apps when I get to room B. jkdufair posted a comment on another thread that I found interesting. https://developer.apple.com/forums/thread/790041?answerId=860905022#860905022 This comment seems to indicate that having a Photos widget in the room can trigger this "can't translate" manipulation issue. I did a quick test by removing my photos widget, but it did not help. Another forum uses suggested reformatting the device solved this for them. I'd like to avoid that if possible, but if it is absolutely necessary then I can. https://developer.apple.com/forums/thread/790041?answerId=859395022#859395022

No one has any information on Unified Coordinate Conversion? It was good enough to appear in several WWDC slides, but isn't worth documenting or explaining?

@Vision Pro Engineer I ran into a similar issue and filed a feedback with steps to reproduce this FB19610114 Here is a thread with more details. https://developer.apple.com/forums/thread/796861 Be aware, this only ever happens on the device, not in the simulator. Don't waste any time trying to reproduce it in the Simulator

No one at Apple has a few minutes to look at this feedback or comment on this? I'm not exaggerating when I say that this is a critical bug. If this ships in visionOS 26 it will reflect badly on any developer using Manipulation Component.

The simulator has an issue where it doesn't raise this error. Widgets do require this background to work. Here is an example from one of mine. You will need to add containerBackground to the view. struct EmojiWidget: Widget { let kind: String = "EmojiWidget" var body: some WidgetConfiguration { AppIntentConfiguration(kind: kind, intent: EmojiConfigurationAppIntent.self, provider: EmojiProvider()) { entry in EmojiWidgetEntryView(entry: entry) .containerBackground(.white.gradient, for: .widget) } .supportedFamilies([.systemLarge]) .supportedMountingStyles([.elevated, .recessed]) .widgetTexture(.paper) .configurationDisplayName("Emoji Circle") .description("Adjust the number of emojis in a radial layout") } } You can optionally make this removable (let the system replace it with other backgrounds) by adding this AppIntentConfiguration{...} .containerBackgroundRemovable(false)

@Vision Pro Engineer Thanks, Feedback filed FB19948223

I think that is just the app reordering mode. It doesn't apply to environments today, but maybe they plan to let users rearrange our environments like we can with app on the first tab.

There is a hidden element we can "look at" with the mouse cursor. Place you mouse somewhere in this area This will show a tiny little button you can tap. It can be hard to see, but it is there. Tapping that will open control center. It sometimes takes a few seconds to load.

I made a standalone project based on your code check this out. The good news that the entity is not being duplicated. Let's look at the cod first. struct ImmersiveView: View { @State var launchEntity = Entity() var body: some View { RealityView { content in print("RealityView Content Loaded!") // Called Once launchEntity = createLaunchEntity() content.add(launchEntity) } } func createLaunchEntity() -> Entity { //... let entity: Entity = Entity() entity.name = "Launch Entity" let launchviewComponent = ViewAttachmentComponent( rootView: LaunchView() ) entity.components.set(launchviewComponent) print("createLaunchEntity was called") // Called Once return entity } } struct LaunchView: View { var body: some View { VStack { Text("Launch View") } .padding() .onAppear() { print("Launch view appears!") // Called Twice } } } When I load this immersive space I see 4 lines in the console RealityView Content Loaded! createLaunchEntity was called Launch view appears! Launch view appears! What happened RealityView content was called once createLaunchEntity The onAppear closure in the LaunchView was called twice. That made me wonder if ViewAttachmentComponent is calling LaunchView more than once and yes, that appears to be the case. When I create the attachment using the attachments closure on RealityView, onAppear is only called once. var body: some View { RealityView { content, attachments in print("RealityView Content Loaded!") // Called Once content.add(launchEntity) if let attachment = attachments.entity(for: "Test") { launchEntity = attachment content.add(launchEntity) } } update: { content, attachments in } attachments: { Attachment(id: "Test", { LaunchView() }) } } So the good news is that we don't see duplicate entities in the graph. The bad news is that ViewAttachmentComponent is calling the SwiftUI more than once. I suggest you file a bug with Feedback Assistant. In the meantime, you could using RealityView to create attachments. If your view is just presenting data, then I suppose you could just ignore this.

I ran into something like this in Beta 1 back in June. At first I thought it was something related to RealityKitContent as that is where Xcode seemed to be stuck. It ended up not having anything to do with RealityKit. One of my example code files demonstrated how to use every ornament anchor. This worked well on previous versions, but Xcode 26 could not compile it. Can you look at your SwiftUI code and see if there is anything with lots of ornaments, toolbars, that sort of thing? You may want to start commenting out sections of the view hierarchy and see if you can get it to build. Once it builds, start re-activating views until you can cause the issue again. That may help you find the view that Xcode is getting stuck on.