For me, any View that is an Attachment will rebuild at full frame rate even with nothing changing, indeed, even with no variables in the view. In addition to causing CPU usage that isn't needed, if there are @State variables in the View they do not always update. I am updating the var on DispatchQueue.main.async and most of the time it works. On occasions it is updated instantly. On other occasions it might take 30 seconds or more before the var changes are visible. If I set a BP where the @State variables are changed I can see that the change... but the new value is not visible in the View (on VisionPro). I have also used print("title (\title)") and I can see the correct version in the console but what you see in AVP in the View is not correct (though it will, eventually update). Important to note, 70% of the time the values are updated immediately. I've tried @StateObject with a class with ObservableObject and while that made it better, it doesn't fix the issue. The App is in FullImmersion at the time. I have no way of knowing if the is related or not. Below is the latest iteration of the variable. @StateObject var alertState = AlertState() class AlertState: ObservableObject { @Published var description: String = "" @Published var title: String = "" }

While WorldTrackingProvider.removeAnchor() completes without error, the WorldAnchor might be back the next time the App is run. This can easily be replicated by the ObjectPlacement sample. Just add 10 objects, Remove All, then run App again. The first run the anchors might be gone, but run the App a couple more times and the anchors will come back. This becomes a big problem when paired with the issue that anchors are not always found when the App enter Immersive mode. When an anchor is not found our App will add an anchor. That usually works fine for that run. The next run, however, the other anchors will show up. Anchors accumulate and it becomes difficult to track.

This is easy to replicate with the ObjectPlacement sample app. Just run the app, position the View behind you and enjoy building a tower with the blocks. Eventually the App will enter the background and exit Immersive Space. This is actually a big problem because while you can ignore the change of scenePhase to .background this removes the chance you have to knowing the user pinched the circle X button to close the view. You can run the Hello World app, enter Immersive Space and then close the View. Immersive Space stays up and you can't get the View back. As such you need to close Immersive Space if the user closes the View (like ObjectPlacement does). Obviously if you do that and the user doesn't look at the View then it exits Immersive Space. Either option is a bad user experience. Being able to hide the View while in Immersive Space (such that the user can't close it) would be a good option. Unfortunately while you can hide all the content, the bar and circle X button are still visible. A second option would be to have the View not go into the background if the user doesn't look at it iff they are in Immersive Space.

We have a random issue that when ARKitSession.run() is called, monitorSessionEvents() receives .paused and it never transitions to .running If we exit Immersive Space and do ARKitSesssion.run() again it works fine. Unfortunately this is very difficult to manage in the flow of our App.

I'm on VisionOS 1.2 beta and Instruments will capture everything but RealityKit information. RealityKit frames and RealityKit metrics captures no data. This used to work though I'm not sure what version it did. Unbelievably frustrating.