This was fixed in visionOS 1.0 beta 4.

This was fixed in visionOS 1.0 beta 4.

As of visionOS 1.0 beta 4, even though defaultSize results in a janky resize animation when the app launches, it you force-quit the app by killing it from Terminal and relaunch it from the visionOS home screen ... twice ... then visionOS somehow seems to remember what the window's last runtime default size was and your app's launch window will reflect that size for future runs. This state is lost each time you launch the app from Xcode. I have no idea if apps have this behavior on the device, or what the behavior will be the first time an app is launched after being installed from the App Store. None of Apple's system apps, like Safari or Settings, appear to feature the awkward launch window resize animation problem. It would be nice to know what Apple's plan is for visionOS launch window sizes for third party apps.

lol

The UILaunchPlacementParameters approach no longer works in visionOS 1.0 beta 4.

This does not work in Version 15.1 beta (15C5028h)

Here is my Info.plist that works in Xcode 15.0 beta 8, based on the reply posted by @atbf earlier. This launches the app directly into a full immersive space. Curiously, the user was not prompted for permission first, as they are when openImmersiveSpace is called.

@raldrich Hi, did you ever figure this out? I am following this same path and I am surprised that MeshDescriptor does not appear to define a vertex color option. Maybe the answer is to define a custom buffer and then, at least on visionOS, hope that it's possible to define a shader graph that accesses the custom buffer.

@atbf fyi, in the feedback that I submitted for this bug (FB13143132) an Apple engineer responded. They said they were able to reproduce this issue, they believe they have addressed the problem, and a fix will be included in an upcoming release. ❤️

By "if I later update the attachment to display a different set of controls", what I meant is that the reality view's RealityViewAttachments and my attachment's corresponding entity remains unchanged, but my attachment's view is repopulated with a different set of controls depending on several if/then statements. The set of controls can also change dynamically over time in response to user action. (I only ever have one attachment.) I should have time tomorrow to experiment with this more. Thank you for the suggestions.

The size of the first window an app presents is defined by the UILaunchPlacementParameters and PreferredLaunchSize keys in the Info.plist file. This size is also used while the app is still loading. I couldn't find this documented anywhere, so it's possible it will change in the future.

@tracyhenry I think I figured it out. I think I figured out the problem through experimentation, and GroundingShadowComponent actually does work. I think when you read a model from a USDZ file, you can't simply assign the GroundingShadowComponent to the root entity of the entity hierarchy that's in the USDZ file. GroundingShadowComponent must be assigned to each ModelEntity that's in the USDZ file hierarchy. This would explain why GroundingShadowComponent worked when directly assigned to sphereEntity in your code, because it's a ModelEntity. Assuming the existence of Entity/enumerateHierarchy, defined below, you could write something like this after you load the entity from the USDZ file: usdzFileEntity.enumerateHierarchy { entity, stop in if entity is ModelEntity { entity.components.set(GroundingShadowComponent(castsShadow: true)) } } This worked for me when I tried it. import RealityKit extension Entity { /// Executes a closure for each of the entity's child and descendant /// entities, as well as for the entity itself. /// /// Set `stop` to true in the closure to abort further processing of the child entity subtree. func enumerateHierarchy(_ body: (Entity, UnsafeMutablePointer<Bool>) -> Void) { var stop = false func enumerate(_ body: (Entity, UnsafeMutablePointer<Bool>) -> Void) { guard !stop else { return } body(self, &stop) for child in children { guard !stop else { break } child.enumerateHierarchy(body) } } enumerate(body) } }

I tried setting GroundingShadowComponent on a ModelEntity read from a USDZ file and it didn't work for me either in Xcode 15 beta 2.

Never mind, I was trying ARKIt grounding shadows, not the RealityKit grounding shadows. I will continue investigating...

Hi @tracyhenry did you ever make any progress on this issue? I'm in the same situation. It appears to me that the visionOS simulator doesn't support grounding shadows. It's possible that they'll work on a physical headset, but there's no way to tell yet. Also with respect to lighting, where do you see that the docs say that DirectionalLight is actually supported on visionOS? I first looked into this on Monday July 31 and the DirectionalLight doc page didn't include visionOS in the list of supported platforms for DirectionalLight (or any other light types). I've also seen a WWDC Slack Q&A post that strongly implies that any sort of traditional lights or depth map shadows aren't supported on visionOS, only environment lighting and the grounding shadows. I haven't yet seen evidence that grounding shadows will work in any context. fwiw, even if grounding shadows work, I assume they're going to put a shadow of your ground plane square on the floor below it, and your rocket won't cast shadows onto your ground plane square.