I did a test and hand-edited a USDA file to include a fictional future visionOS 3.0 shader node graph property, to see how RealityKit responds to this scenario on visionOS 2.0: On visionOS 2.0, ShaderGraphMaterial(named:from:in:) fails with the same error that is currently returned on visionOS 1.0: The operation couldn’t be completed. (RealityFoundation.ShaderGraphMaterial.LoadError error 1.) (although curiously it returned error 1 that time instead of error 0) So, it would seem that unless changes are made, we'll experience this problem again next year with Reality Composer Pro 3.0, which will blindly output shader graph nodes that can't be read by visionOS 2.0.

Thank you for responding. Just to be clear, and to help out other visionOS developers who encounter this issue and save them time, are all of the following true? (as of Xcode 16.0 beta 5) On visionOS 1.0, RealityKit's ShaderGraphMaterial(named:from:in:) (and possibly other APIs) will fail when used to load a shader graph material created using Reality Composer Pro 2.0 that references a new visionOS 2.0 shader graph node or shader graph node property that isn't supported by visionOS 1.0. The error message generated by ShaderGraphMaterial(named:from:in:) is The operation couldn't be completed. (RealityFoundation.ShaderGraphMaterial.LoadError error 0.). The error does not indicate which shader graph node or shader graph node property has caused the failure. To determine the specific cause of the failure, the developer must resort to time consuming techniques like a manual binary search. Reality Composer Pro 2.0 doesn't display a warning if the developer creates a shader graph node that isn't supported by visionOS 1.0 or modifies the value of a new shader graph node property that isn't supported by visionOS 1.0. The Reality Composer Pro shader graph documentation at https://developer.apple.com/documentation/shadergraph doesn't indicate which shader graph nodes and shader graph node properties are new visionOS 2.0 beta features that aren't supported by visionOS 1.0. For third party developer projects that are required to support visionOS 1.0, Apple's recommended workaround is to avoid using Reality Composer Pro 2.0, and to use Reality Composer Pro 1.0 instead. This known issue and Apple's recommended workaround are not included in the Xcode 16.0 beta 5 release notes. Please let me know if any of that is inaccurate. Another question: Can you please tell me if Apple is tracking these issues and plans to address them in future visionOS 2.0 betas, either with a Reality Composer Pro update, or with updated shader graph node documentation, or in the Xcode 16.0 beta release notes? I'd be happy to submit additional feedback about each of these individually, but I am hesitant to waste any more of my time if Apple has already prioritized fixes. However, if you are able to communicate to me that Apple currently has no plans to fix any of this, then I'll submit more feedback if that would be helpful. Thank you.

After more investigation, I think one possible cause of this issue may be the "Image 2D (RealityKit)" node type, and only if the new "Use MaterialX V Origin" parameter is enabled (or enabled and later disabled). It's possible other node types or parameters are affected as well.

For the case of opacity, this Entity extension provides setOpacity(_:animated:duration:delay:completion:) which lets you animate that property: https://gist.github.com/drewolbrich/1e9d3da074c8a1d5ca93721124b97596 It's implemented in terms of OpacityComponent and FromToByAnimation.

Thank you for responding. I will try to create a sample app that reproduces the issue.

I don't know yet if this is reproducible, but I deleted my app, reinstalled it via TestFlight using visionOS 2.0 beta 4, presented a full immersive space in the app, and then I saw the Stay Aware of Your Surroundings alert. So, that is a possible means of reproducing the new visionOS 2 full immersive space behavior.

I've discovered that one workaround is to temporarily load your project in Xcode 16.0 beta 2 and use that to add the frame to the target, and then switch back to Xcode 16.0 beta 4. In the case of a local Swift package, another workaround, using Xcode 16.0 beta 4, is to add the package at the project level using the UI normally intended for adding remote packages, but selecting the local package option, and also selecting the option to add the package to a specific target. Once this is complete, remove the package from the project. The local package will remain associated with the target.

This issue does not occur in Xcode 16.0 beta 2 (16A5171r).

I updated to Xcode 16.0 beta 4 (16A5211f) and I am experiencing the same issue.

I agree it's a welcome change. The user experience is much better this way. Since I updated my device to visionOS 2 beta, I've installed my app via TestFlight multiple times, and I don't think I've seen the notice you described except once, immediately after I first installed visionOS 2 beta. So, it appears this is not something I can easily test without reinstalling visionOS 2. Also, since I no longer have visionOS 1 installed, there's now no easy way to test the original visionOS 1 immersive space permission alert either. The visionOS 1 simulator has never supported presentation of the immersive space permission alert, so that's not an option. This is all unfortunate, but thank you for responding. It's helpful to know I'm not overlooking something obvious.

Apple's WWDC24 video "Optimize your 3D assets for spatial computing" states recommended max triangle counts at 2:33 https://developer.apple.com/wwdc24/10186?time=153 This video is wonderful.

For anyone reading this in the future, in visionOS 2, ShaderGraphMaterial now supports faceCulling: https://developer.apple.com/documentation/realitykit/shadergraphmaterial/faceculling-swift.property

I've investigated this issue frequently since it first in Xcode appeared 5 years ago, and the only way I've found to actually fix the issue is to run this in Terminal: rm -rf ${HOME}/Library/Developer/Xcode/DerivedData That will permanently get rid of the phantom warnings and errors you're seeing. However, you'll have to run this again each time new warnings and errors appear. The other downside is that after deleting the DerivedData folder, you'll have to do a full rebuild of your project, which can be time consuming. The suggested solution, using Product > Clear All Issues, only removes the warnings and errors temporarily. They will usually return the next time you build your project.

(deleted)

This seems to work for me: // If we don't use `DispatchQueue.main.async` here, `withAnimation` has no effect. DispatchQueue.main.async { withAnimation { scrollViewProxy.scrollTo(id) } }