I have the same issue. Removing/adding devices does not solve the issue for me.

Xcode 12.3 causes this problem for me. Unpairing devices does not resolve the problem.

Still experiencing this problem after upgrading to 12.4 on MacBook Pro 15 and DTK under MacOS 11.2 and on iMac 27" running under Catalina. Turning off "Connect via network" on the MacBook Pro caused Xcode to crash (sigh). Seems like the issue is getting worse.

Sigh, still a problem in iOS 15.4.1

The problem is in present even in USDZ files created by Apple and displayed in AR Quick Look. It's sad that the problem has remained for so many years. Below you see a screen shot of the Apple Tea cup demo USDZ in AR Quick Look on an iPhone 12 Max running iOS 15.5. Below that is the AR view in a 5500K lightbox with an Apple mouse on a white sheet of paper for reference. 'nuff said.

I too have an app that uses SceneKit with ARKit to frame pictures and lay them out in galleries in a room. I would hope to use my SCNNodes seamlessly with RoomPlan. I'm very interested in the answers to this question.

I understand that the "new lighting" feature also adjusts "contrast", which is not adjusted by "lighting" and "lightingEnvironment". How would I adjust scene contrast in SceneKit and RelityKit as it is done in AR Quick Look?

Ditto: Same problem with instruments Version 14.1 (14B47b) iOS 16.1.2 iPhone 14 Pro Max

FB17945555 generated. Thank you for the prompt reply. I was looking to explore what would happen with a clear background in an effort to make my control panel less obtrusive. I'm not sure I have an application for it yet other than exploring design options. HOWEVER, perhaps the compiler error could be downgraded to a compiler warning. In other cases where functionality is missing (I'm looking at screenshots :( ) and their code is 1. not generated or 2. invocations generate no warnings and fail silently. Proposal: Replace the error with a warning and simply ignore the use of .glassEffect() on visionOS. That should save developers a lot of unnecessary #if coding at the risk of their visionOS UI breaking in the future should .glassEffect() be implemented in visionOS and the warnings disappear.

FB17946994 filed

Thank you for your response. I will look into the use of RealityRender, but it only partially addresses the need. My application and others that involve interior design require that the design be evaluated in the environment where it will exist. For example, my app “FrameIt Vision” (https://itunes.apple.com/app/id6472856422) allows users to frame, mat, and arrange images from Photos on their walls in the room where the arrangement will be displayed. The key advantage to a Vision Pro is its ability to design in the room where the picture will be displayed. At the end of the design process, the designer must share the design quickly and easily with very non-technical people who are responsible for framing and installation. The best answer is to handoff an image (screenshot) that shows the creation in the environment where it will be installed. Any solution that excludes the installation premises is only a poor partial solution. In regards to option 2. My app already exports Reality files. They are a poor partial solution, but the best that can be done today. In addition, my app already provides a PDF report that lists the specifications of frames, mats and arrangements. Unfortunately, it is very difficult for most to grok dimensions, color names, and locations in a multipage report.

Hi Michael, Thank you for the quick reply. This is my code on visionOS 26 beta 2 using your path for the temoraaryDirectoryURL: @MainActor func writeArrangementToTemp() async -> URL? { var tempURL: URL? = nil if let quickLookArrangement = makeFramedPicturesArrangementEntity(), let sceneName = gallerySceneRootEntity?.gallerySceneData?.name { let temporaryDirectoryURL = Foundation.FileManager.default.temporaryDirectory let fileURL = temporaryDirectoryURL.appendingPathComponent("\(sceneName).reality") do { _ = FileUtilities.deleteFile(url: fileURL) try await quickLookArrangement.write(to: fileURL) myLog("Wrote reality file to \(fileURL)") } catch { myLog("Failed to write reality file \(error)") } tempURL = fileURL } return tempURL } These are my log file entries 2025-06-30 11:34:14.016 Oops: delete failed Spring 2025.reality error “Spring 2025.reality” couldn’t be removed. 2025-06-30 11:35:51.443 Failed to write reality file Error Domain=RERealityFileWriterErrorDomain Code=10 "Could not create parent folders for file path /var/mobile/Containers/Data/Application/C007D73C-5B2C-4F80-B243-D5C0C337731B/Library/Caches/com.GeorgePurvis.Photography.FrameItVision/RealityFileBundleZippingTmp_E655E7B5-6258-43EA-9C33-FEA2343EA0D8/63E04105-B3E6-483F-918B-53758F8925EA." UserInfo={NSLocalizedDescription=Could not create parent folders for file path /var/mobile/Containers/Data/Application/C007D73C-5B2C-4F80-B243-D5C0C337731B/Library/Caches/com.GeorgePurvis.Photography.FrameItVision/RealityFileBundleZippingTmp_E655E7B5-6258-43EA-9C33-FEA2343EA0D8/63E04105-B3E6-483F-918B-53758F8925EA.} The deleteFile() failure is expected since the temporary directory has not been used before and is expected to be empty. Commenting out the deleteFile makes no difference. The error message remains the same. Your test creates a simple null Entity(). Real Entities like mine have children, materials and meshes. When trying to reproduce, please use entities with children, custom meshes and materials. The problem seems to be related to caches that write(to:) needs to create probably for these children, meshes and/or materials.

Hi Michael, I am encountering an error "Unable to open an immersive space when the app does not support multiple scenes" when I attempt to build a minimal immersive space app strictly in Swift 6.2 without any RealityKit resources. For the example project, please look at FB18515832. Note that the Info.plist is autogenerated by Xcode. I get the same message when it is manually generated. George

Thank you, Michael. Yes that does identify the problem and I have a working test project (EntityWriteToTest) that has no problem correctly saving with entity.write(to:) with trivial test cases. I am now beginning the lengthy task of construction test entities using the app's custom meshes and materials. The strange thing in the "FrameIt Vision" app error message to me are: • that entity.write(to:) is trying to use the file path "/var/mobile/Containers/Data/Application/C007D73C-5B2C-4F80-B243-D5C0C337731B/Library/Caches/com.GeorgePurvis.Photography.FrameItVision/RealityFileBundleZippingTmp_E655E7B5-6258-43EA-9C33-FEA2343EA0D8/63E04105-B3E6-483F-918B-53758F8925EA." that seems like a long path name ending with a '.' [period] • The problem seems to be generated during the RealityFileBundleZipping stage of creating the .reality file by the write(to:) api • I'm guessing that materials and perhaps meshes are external to the usda file contained in a .reality file and are being zipped.

I have switched to testing in Simulator Vision Pro (4k) for visionOS 26 beta 2. On the simulator, the app writes .reality files with entity.write(to:) without errors and QuickLook subsequently opens the .reality file displaying it correctly. When I switch to deploying the exact same code on device, the Vision Pro is errors almost immediately on the call to entity.write(to:) with this error 2025-07-01 16:32:50.187 6 framed pictures in the arrangement 2025-07-01 16:32:50.202 🚫 Failed to write reality file file:///private/var/mobile/Containers/Data/Application/B36B01AB-6223-4A69-A79E-227BF35AAEBA/tmp/Empty%20.reality Error Domain=RERealityFileWriterErrorDomain Code=10 "Could not create parent folders for file path /var/mobile/Containers/Data/Application/B36B01AB-6223-4A69-A79E-227BF35AAEBA/Library/Caches/com.GeorgePurvis.Photography.FrameItVision/RealityFileBundleZippingTmp_D373CAF9-7901-42BC-AD74-EF159279788B/FBE36B9F-AA71-4BEE-805B-83CD7CCB0CD8." UserInfo={NSLocalizedDescription=Could not create parent folders for file path /var/mobile/Containers/Data/Application/B36B01AB-6223-4A69-A79E-227BF35AAEBA/Library/Caches/com.GeorgePurvis.Photography.FrameItVision/RealityFileBundleZippingTmp_D373CAF9-7901-42BC-AD74-EF159279788B/FBE36B9F-AA71-4BEE-805B-83CD7CCB0CD8.} The visionOS 26 simulator correctly handles the entity.write(to:) suggesting that the meshes, textures, and entity structure being written is both correct and written correctly. On device, visionOS 26 beta 1 and 2 seem to have some changes to file permission or sandboxing that are not present in visionOS 2.5 and visionOS 26 simulator.