Thanks for confirming. I’ve filed this in Feedback Assistant as FB25114901: “RealityKit: empty CollisionFilter prevents input on macOS and iOS.”

@Vision Pro Engineer There is clearly something else going on. But I thought a better video is worth a thousand words. I have made it extremely clear in this reproduction. it happens even when far away from the presentation component as you can see now please watch this 1 min video at https://github.com/mesqueeb/PresentationAutoCloseInBackOfVolume The code used there is pushed to the github repo.

I hope to get back to properly test this soon, but someone pointed out it might be orientation: .init() it creates an invalid simd_quatf instead of a non-rotated valid one. 🤦🏼‍♂️ That's probably it....

Did anyone test on macOS v27 beta?

Reported via FB22755700

Hi Ziqiao, Yes — I spent a full day isolating this into a standalone Swift package: https://github.com/mesqueeb/SwiftDataContainerPollutionInTests git clone https://github.com/mesqueeb/SwiftDataContainerPollutionInTests.git cd SwiftDataContainerPollutionInTests ./test.sh 20 The script runs xcodebuild test in a loop (also reproduces with swift test). It was tricky to minimize — the bug triggers roughly 1 in 15–20 runs with these simplified schemas, but in my real project with more complex Codable types and more schema versions it triggers ~5 out of 6 runs. The more I stripped away to isolate the reproduction, the lower the trigger rate got, but the core issue is the same. Regarding erase(): I tried it in my real project and it didn't help. Each in-memory container already uses a unique ModelConfiguration name (UUID().uuidString), so they shouldn't be sharing any state — the pollution seems to come from the process-global schema registry rather than from any individual container's store.

To clarify i'm on macOS 26.3.1 (a) the reported environment was wrong, but I cannot edit the OP.

Happened to me after just signing in this morning, around 12h later it already got that error: Failed to authenticate. API Error: 401 {"type":"error","error":{"type":"authentication_error","message":"OAuth token has expired. Please obtain a new token or refresh your existing token."},"request_id":"req_0xxxxxx"} Signing out of Claude.ai account in the "Agent" settings and back in worked.

@JosephSimpson Did you notice any change in behaviour since last year? Or any further communication from Apple via your feedback tickets?

@Vision Pro Engineer thank you for the sample and suggestion to use an ECS system to do so. I was hoping for an action similar to the fromToByAction: https://developer.apple.com/documentation/realitykit/fromtobyaction that we can apply to the intensity, just like we can with other properties like position etc. Do you know if this is possible?

@isomoon @rakesha @steve23 Take a look at my article here: https://fatbobman.com/en/posts/merging-swift-string-catalogs-in-a-multi-package-monorepo/

I have the same issue. Does this mean that any visionOS apps cannot use Xcode Cloud?

@Lucky7 Did you figure it out? I was wondering the same thing.

To answer my own post with my current understanding on things: 1- Does IBL need to be BW or will colour work? It can be in colour. As an example you can use Reality Converter to test multiple different IBLs, some b/w some coloured: 2- What is the best file format for IBL? Any pros/cons? Or should we just test out each format and check visually. From my tests: PNG, OpenEXR (.exr), Radiance HDR (.hdr) all work. But which format is recommended? It "depends". Just test and see until you have the ambience you are looking for. 3- Will IBL on visionOS create shadows for us? In Blender an HDRI gives shadows. No. There is currently no clear information what the best way is to approach adding shadows to a scene in RealityKit. 4 Looking at a scene in Blender which uses HDRI as global lighting, how can we best "prep" the IBL image that will give the closest light similar to Blender's Cycles rendering engine? Just test and see until you have the ambience you are looking for.

@Wittmason with "shadow baking" I meant "light baking". What I really mean is that in the Blender renderer (the screenshots at the bottom) you can see beautiful shadows. They are not generated when running on the  Vision Pro. An IBL will "tint" our assets' colour, but it will not add shadows. I think the only solution to have shadows is to replace the textures with textures that have those shadows baked in. I guess they call this "light baking" in Unity/Unreal, but Blender doesn't have a good workflow for this. My current understanding: an asset texture as a JPG is sometimes a smaller image used in repeated pattern on an asset other times an asset texture is just colour/texture data, not using any jpg In consideration of the above, what I understand the limitations of light baking to be: When baking light onto a JPG texture (so you can see a shadow as part of that texture), then you basically need one big texture jpg per asset and cannot use any "repeated pattern" any more. When baking light onto a texture that doesn't use any JPG but instead colour/texture data, then a newly JPG will need to be generated for that. The above 1 & 2 makes it so the usdz file size will grow tremendously because of the new and large sizes texture JPGs... I believe that Unity/Unreal therefore don't "bake light onto a texture" but instead they create a "lightmap" which is another layer that can be added on top of an asset with data on which parts need to be lightened/darkened. I am guessing this is a more economical method to do so, but I have no idea how these lightmaps are supported by RealityKit /  Vision Pro.