So what can you do if you find a root-owned file that is preventing your app from running? Here are the steps I followed to remove the offending files: Next steps: • In Xcode connected to Vision Pro, download the app's container to preserve app data for reloading later • On Vision Pro, delete the app thereby destroying the app’s container which should delete any root owned directories and files as well as all data • Download the app from the App Store • Test that code encountering the issues [in this case entity.write(to:)] is working and that the result is as expected [in this case check that .reality file automatically opens QuickLook as expected]. • If successful resume app development on visionOS • Build and run the development version of the app on the Vision Pro device • Test that code [in this case entity.write(to:)] is still working Optional steps to restore the app's data: [Note these optional steps may not work if the development version container data store needs migration] • After a successful test, download the app container to the Mac • Copy the previous container’s Application Support folder into the newly downloaded container • Replace the app container on Vision Pro with the modified container • Build and run the development app version on the Vision Pro device • Test that the code [e.g. write(to:)] is still working Following the steps above solved the root corruption for me and allowed continued app development. However, the fix does not solve the fundamental issue of how some app with root permission on visionOS left files in my app's sandbox which prevented my app from executing a key capability.

An interesting coincidence: visionOS 2.5 RC was released April 28, 2025 the same day the root owned directory and file were created.

It appears that the answer to this issue might be found in the ownership of the Caches files. The following is the output from a scan for files owned by root: App container root: file:///var/mobile/Containers/Data/Application/A155B86A-E9FA-4566-927A-9AF2B0DC0746/ ❌ Could not check /private/var/mobile/Containers/Data/Application/A155B86A-E9FA-4566-927A-9AF2B0DC0746/.com.apple.mobile_container_manager.metadata.plist: The file “.com.apple.mobile_container_manager.metadata.plist” couldn’t be opened because you don’t have permission to view it. 🚨 Root-owned item found: /private/var/mobile/Containers/Data/Application/A155B86A-E9FA-4566-927A-9AF2B0DC0746/Library/Caches/com.GeorgePurvis.Photography.FrameItVision NSFileOwnerAccountID: 0 NSFileGroupOwnerAccountName: mobile NSFileReferenceCount: 4 NSFileType: NSFileTypeDirectory NSFileExtensionHidden: 0 NSFileSystemNumber: 16777226 NSFileAppendOnly: 0 NSFileGroupOwnerAccountID: 501 NSFileOwnerAccountName: root NSFileImmutable: 0 NSFileSystemFileNumber: 17595554 NSFileSize: 128 NSFileModificationDate: 2025-04-28 17:02:47 +0000 NSFileCreationDate: 2025-04-28 17:02:40 +0000 NSFilePosixPermissions: 493 🚨 Root-owned item found: /private/var/mobile/Containers/Data/Application/A155B86A-E9FA-4566-927A-9AF2B0DC0746/Library/Caches/com.GeorgePurvis.Photography.FrameItVision/com.apple.metalfe NSFileGroupOwnerAccountName: mobile NSFileImmutable: 0 NSFileAppendOnly: 0 NSFilePosixPermissions: 493 NSFileType: NSFileTypeDirectory NSFileSystemNumber: 16777226 NSFileGroupOwnerAccountID: 501 NSFileExtensionHidden: 0 NSFileReferenceCount: 2 NSFileSystemFileNumber: 17595555 NSFileSize: 96 NSFileOwnerAccountID: 0 NSFileOwnerAccountName: root NSFileModificationDate: 2025-04-28 17:02:40 +0000 NSFileCreationDate: 2025-04-28 17:02:40 +0000 ❌ Could not list contents of /private/var/mobile/Containers/Data/Application/A155B86A-E9FA-4566-927A-9AF2B0DC0746/SystemData: The file “SystemData” couldn’t be opened because you don’t have permission to view it. Could this be the cause of the problem? I am unable to delete the root owned files in my sandbox. How do directories and files become owned by root? [I certainly cannot do it from standard code.] Why are these two files owned by root? This is the ChatGPT code that scanned the app directory tree: import Foundation func checkForRootOwnedItems(at url: URL, indent: String = "") { do { let contents = try FileManager.default.contentsOfDirectory(at: url, includingPropertiesForKeys: nil) for item in contents { do { let attributes = try FileManager.default.attributesOfItem(atPath: item.path) if let ownerID = attributes[.ownerAccountID] as? NSNumber { if ownerID.intValue == 0 { // UID 0 is root print("🚨 Root-owned item found: \(item.path)") for (key, value) in attributes { print("\(indent) \(key.rawValue): \(value)") } } } var isDir: ObjCBool = false if FileManager.default.fileExists(atPath: item.path, isDirectory: &isDir), isDir.boolValue { // attempt to recurse checkForRootOwnedItems(at: item, indent: indent + " ") } } catch { // you couldn't even read this file or folder: print("❌ Could not check \(item.path): \(error.localizedDescription)") } } } catch { // this directory itself couldn't be listed: print("❌ Could not list contents of \(url.path): \(error.localizedDescription)") } } // Usage: if let rootURL = FileManager.default.urls(for: .applicationSupportDirectory, in: .userDomainMask).first? .deletingLastPathComponent() .deletingLastPathComponent() { checkForRootOwnedItems(at: rootURL) }

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.

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.

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

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.

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.

FB17946994 filed

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.

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

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?

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.

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.

Sigh, still a problem in iOS 15.4.1