I would also like the option to purchase a cable-connector for Vision Pro so I can avoid problems associated with wireless debugging.

I believe the “update” method of your RealityView will fire when your entity appears in the scene. You could check the .scene property of your entity at that time and observe it is non-nil.

I could be wrong, but if something is positioned between the limb and the headset, I don’t think it should be occluded. I did not hear back about debits, though, so I don’t know for sure.

Vision OS does not expose the location a user is looking via the API.

Yeah, I get the same behavior. There are a few posts here of others finding the same behavior too. I think you can only get location information relative to the AnchorEntity’s origin from that entity and its children. In addition, AnchorEntities and their children cannot behave in physics based interactions outside of that anchors hierarchy and that includes ray casting. I’ve been endeavoring to never use an AnchorEntoty because of these limitations. Thankfully the plane provider that works on device doesn’t require those entities or else I would be sunk.

Same problem. Would love to know the right way to implement this pattern with @observable

I think searching with skybox may help you find your answer, but I’ve never personally done this.

All I know is that you won’t be able to use “hover” states to detect if the users eyes are actually resting on ad content. Other than that I have not heard of any limitations. I‘m looking forward to apps that can put black squares over billboards in real life. :D

I believe you can generate a collision Shape from a mesh. Thats the recommendation for creating entities when using a SceneReconstruction provider, for example. See the raycasting portion ARKit and spatial computing WWDC video for slightly more.

As VisionOS is not yet a "Released" OS, it is not available in the non-beta versions of Xcode. Like the other poster said, you need to open up a beta version like the release notes say.

Correct. You can place your own plane, give it a collision shape, and use that to test for the time being.

One more: What if the user is holding something for away and they rotate their torso away from it? Will it follow along or stay static?

Yeah, it felt really misleading, but Apple's developer communication is usually about this bad.

It will compile, but I believe it won't fire so we can't track user's eyes.

Number one is prevented for privacy reasons. There are some ways to communicate to the system which shape should be used when a hover is occurring, but there is no way to act on the event. The Hover highlighting is even performed out-of-process so it can't be used maliciously, such as my ad-companies. Number Two I don't know Number three may be called "Billboarding" and there is an example of that in the splash splash sample code.