Possibly related: Sometimes, in the iOS 18 simulator only, the ARView appears black and none of my app's geometry is rendered.

Possibly related: While collecting the fully symbolicated crash logs I posted in an earlier comment, three times, in the iOS 18 simulator only, my app hung while loading geometry for a RealityKit scene. I paused the app in the debugger and saw the following stack trace. I couldn't use Xcode > Debug > Detach and get a crash log in this case because the app would hang and did not crash. #0 0x00000001006ec55c in __semwait_signal () #1 0x00000001801695dc in nanosleep () #2 0x00000001801694b0 in usleep () #3 0x00000001aa9cf94c in re::AssetLoadRequest::Data::waitForCompletion () #4 0x00000001aa938068 in re::NetworkSendBlockingAssetLoadRequestManager::flushAndWaitForECSSendBlockingAssetLoadRequests () #5 0x00000001aaee2a98 in re::ecs2::NetworkSendSystem::update () #6 0x00000001aafd013c in re::internal::Callable<re::ecs2::ECSManager::configurePhaseECSSystems(re::Scheduler::ScheduleDescriptor&, re::ecs2::ECSSystemGroup, unsigned long)::$_0, void (float)>::operator() () #7 0x00000001ab463774 in re::Scheduler::executePhase () #8 0x00000001aa8cec10 in re::Engine::executePhase () #9 0x00000001aa8d71cc in re::Engine::timeDidChange () #10 0x00000001ab464da0 in re::Event<re::SimulationTimer, re::SimulationTimerEventArgs const&>::raise () #11 0x00000001ab464cd8 in re::VariableStepTimer::onClockDidChange () #12 0x00000001ab4643f8 in re::Event<re::SimulationClock, re::SimulationClockEventArgs const&>::raise () #13 0x00000001ab4645d4 in re::DisplayLinkClock::update () #14 0x000000018afcfccc in CA::Display::DisplayLinkItem::dispatch_ () #15 0x000000018afcbdac in CA::Display::DisplayLink::dispatch_items () #16 0x000000018afd29f8 in CA::Display::DisplayLink::dispatch_deferred_display_links () #17 0x000000018504aa80 in _UIUpdateSequenceRun () #18 0x00000001859f2750 in schedulerStepScheduledMainSection () #19 0x00000001859f1b88 in runloopSourceCallback () #20 0x000000018041b484 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ () #21 0x000000018041b3cc in __CFRunLoopDoSource0 () #22 0x000000018041ab30 in __CFRunLoopDoSources0 () #23 0x0000000180415210 in __CFRunLoopRun () #24 0x0000000180414ac0 in CFRunLoopRunSpecific () #25 0x00000001906e0b10 in GSEventRunModal () #26 0x0000000185ac325c in -[UIApplication _run] () #27 0x0000000185ac7454 in UIApplicationMain () #28 0x0000000184eb40d8 in UIKit.UIApplicationMain(Swift.Int32, Swift.Optional<Swift.UnsafeMutablePointer<Swift.UnsafeMutablePointer<Swift.Int8>>>, Swift.Optional<Swift.String>, Swift.Optional<Swift.String>) -> Swift.Int32 () #29 0x0000000102c421b0 in static UIApplicationDelegate.main() () #30 0x0000000102c42128 in static AppDelegate.$main() () #31 0x0000000102c4222c in main at /Users/drew/Repos/Baseball/Baseball/Sources/AppDelegate.swift:14 #32 0x0000000100391410 in start_sim () #33 0x000000010026e274 in start () This hanging was preceded by many messages like the following in the Xcode console: Asset 8262083708093167093 Material (Framework)com.apple.CoreRE/pbr.rematerial failure: Asset provider load failed: type 'Framework' -- unknown framework: com.apple.CoreRE load failed: couldn't load '8262083708093167093 Material (Framework)com.apple.CoreRE/pbr.rematerial' (Asset provider load failed: type 'Framework' -- unknown framework: com.apple.CoreRE) AssetLoadRequest failed because asset failed to load '8262083708093167093 Material (Framework)com.apple.CoreRE/pbr.rematerial' (Asset provider load failed: type 'Framework' -- unknown framework: com.apple.CoreRE) load failed: asset loading already has failed '8262083708093167093 Material (Framework)com.apple.CoreRE/pbr.rematerial' (Asset provider load failed: type 'Framework' -- unknown framework: com.apple.CoreRE) Invalid asset: '8262083708093167093 Material (Framework)com.apple.CoreRE/pbr.rematerial' load failed: asset loading already has failed '8262083708093167093 Material (Framework)com.apple.CoreRE/pbr.rematerial' (Asset provider load failed: type 'Framework' -- unknown framework: com.apple.CoreRE) Invalid asset: '8262083708093167093 Material (Framework)com.apple.CoreRE/pbr.rematerial' load failed: asset loading already has failed '8262083708093167093 Material (Framework)com.apple.CoreRE/pbr.rematerial' (Asset provider load failed: type 'Framework' -- unknown framework: com.apple.CoreRE) Invalid asset: '8262083708093167093 Material (Framework)com.apple.CoreRE/pbr.rematerial'

Possibly related: Sometimes, in the iOS 18 simulator only, CustomMaterial(surfaceShader:geometryModifier:lightingModel:) fails and throws the error "The building parameters were invalid". This error is preceded by the following messages in the Xcode console: Error Domain=REMaterialBuilderErrorDomain Code=50 "Program "realitykit::fsSurfacePbr" failed due to invalid argument numbers. Constant buffer count [19] exceeds limit [14]. " UserInfo={NSLocalizedDescription=Program "realitykit::fsSurfacePbr" failed due to invalid argument numbers. Constant buffer count [19] exceeds limit [14]. } Pipeline data for technique SurfaceShaderOpaque failed compilation! Asset 14147473638299271299 MaterialDefinition (Framework)com.apple.CoreRE/surfaceShader.rematerialdefinition failure: Asset provider load failed: type 'Framework' -- unknown framework: com.apple.CoreRE Asset 8115819767006447788 Material (MemoryAsset)asset29.compiledmaterial failure: failed to register asset load failed: couldn't load '8115819767006447788 Material (MemoryAsset)asset29.compiledmaterial' (failed to register asset)

I've created this close reproduction for you. https://github.com/drewolbrich/page-menu-symbol/blob/main/page-menu.pdf 😀

For anybody else encountering this issue: I updated to macOS Sequoia, not realizing that it doesn't support Xcode 15, which includes Reality Composer Pro 1.0. However, it appears that it is still possible to run Reality Composer Pro 1.0 under macOS Sequoia if you launch it directly out of the Xcode 15 bundle, from Xcode.app > Contents > Applications.

As a workaround, I'm freeing up my ARView when not needed and creating a new one later.

Maybe try resubmitting so you get paired with a different reviewer who will review your app faster? Just guessing, though. Sorry that is happening.

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).