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.

I can't reproduce this on my end. I just tried a few of my projects and examples and they are working fine. If I add a print line to the make closure of RealityView, I only see it print once. When I inspect the entity graph I see what I expect to see. I'm using visionOS 26 Beta 5 and the latest Xcode. Some other things to think about. You can use a feature in Xcode to capture the entity hierarchy. When you do this, do you see duplicate entities in the same hierarchy or duplicate hierarchies? https://www.gabrieluribe.me/blog/debugging-realitykit-apps-games-visionos Is there anything higher up in your SwiftUI stack that could be causing your RealityView to be created more than once? If you can post some example code showing the issue I may be able to provide more useful help

I tried this just after WWDC and it works reasonably well. There is a Safari Flag to enable this for Then, look for the option in the menu to the left of the URL – Joseph

@DTS Engineer Can you please be specific? I don't see the answer to my question in either of those articles. How do tell visionOS not to apply a tint color to the background or content of my view? The WWDC session mentions opting out of this when displaying photos, but I don't see how to do that. How do I tell visionOS: "always render this image as it appears without ever trying to tint it."?

We can load a Three JS scene in a WebView, but the WebView itself will always be a 2D plane. It would work more like a window looking into the 3D space. The Three JS scene can't fill the volume. The only workaround I know is to download a model as a USDZ. If you needed to let your users place models in their shared space, this could be an option. Three JS as features to export as USDZ. But this exported file would not be a live Three JS scene anymore, just a USDZ file that users could open with QuickLook