Thank you for the quick response. It's not the answer I was hoping for, but one in line with what I expected. We consider the choice of turning on video effects a user decision, not an app decision. This is a decision I can understand being made by Apple which I don't necessarily disagree with. However, I believe there should be two improvements made: Allow users to grant entitlement-based permission to apps to make the right decision for them. This leaves the ultimate decision with the user, while the app can optimize for its specialized use case. Allow apps to opt out of system video effects. Any app that needs to be in complete control of any effects applied to its video input and output to deliver its core feature needs this. It can't be in Apple's interest to add to the frustration on user side and developer side with the current landscape of especially video call software where every party involved is able to apply their own video effects and mostly does so on an opt-out basis. It does not lead up to any kind of "It just works" UX.

Double check Xcode->Settings...->Locations->Advanced...->Build Location must not be Legacy. I'm on Xcode 15.1 and for me, this wasn't set to Legacy. However, there's also File > Project Settings… > Advanced… > Build Location and that was set to Legacy. Changing it to Xcode Default and reloading the project helped.

You could take a look at this page.

I'm also not 100% sure what OP is after, but it seems to be a window that remains open when opening an immersive space. I only looked into the sample app briefly, but it indeed uses the app's main window for navigation and content presentation, while the immersive space is presented. WWDC sessions seem to promote the full space only as an immersive experience, so I wasn't aware that this is even an encouraged use case.

I don't have a solution on offer, but I believe this is the project that's being presented in the linked session. If it has the sought after behavior, it should be straightforward to reverse engineer it.

It's hard to tell what's going wrong without seeing your actual code. Have you made sure that your tap gesture closure is actually being called? Have you made sure your openWindow statement actually opens the specified window?

@calebmitcler I based my code off the Xcode template app project for visionOS, so my app struct is simply this: @main struct ImmersiveSpaceTestApp: App { var body: some Scene { ImmersiveSpace(id: "ImmersiveSpace") { ImmersiveView() } } }

Also let cameraTransform = Transform(matrix: pose.originFromDeviceTransform) needs to become let cameraTransform = Transform(matrix: pose.originFromAnchorTransform) Attachments work differently now, as well, so that for example } attachments: { Text("Preview") .font(.system(size: 100)) .background(.pink) .tag("previewTag") } needs to become } attachments: { Attachment(id: "previewTag") { Text("Preview") .font(.system(size: 100)) .background(.pink) } }

Looks a lot like an ornament to me.

Since I needed to find a workaround for this issue myself, I played around a little more. As suspected, this definitely is a race condition during the initial RealityView setup. I have a test project set up that adds two buttons and a toggle to the ImmersiveView in Xcode's template project. When I add try! await Task.sleep(nanoseconds: 100 * NSEC_PER_MSEC) at the end of the view’s make closure, all three UI elements are always active in the visionOS simulator on my MBP M2 Pro, 8+4 cores, 16 GB. When I go down to 50 * NSEC_PER_MSEC, all of the UI elements work (most of the time - I’ve had a case where two of the three were active, but the third one, that is added last, wasn’t). When I go down to 30 * NSEC_PER_MSEC, all of the UI elements sometimes work. When I go down to 20 * NSEC_PER_MSEC, none of the UI elements work.

You should give SpatialTapGesture a try. It can be targeted to any or to specific entities with targetedToEntity() or targetedToAnyEntity(). .gesture( SpatialTapGesture() .targetedToEntity(self.videoEntity) .onEnded { _ in Task { openWindow(id: "Video") } } )

This might be the same issue I'm seeing with attachments in the immersive space I mentioned over in this thread. I noticed this happening only with the latest beta 8 and filed a feedback with Apple.

Figured it out. According to the docs, there are two entries that apparently both must be added to Info.plist. Xcode's error message is not helpful in making that understood, since it doesn't reflect the actual error and the missing immersion style can also be set in code. UIApplicationPreferredDefaultSceneSessionRoleKey: UISceneSessionRoleImmersiveSpaceApplication UISceneInitialImmersionStyle: UIImmersionStyleMixed / UIImmersionStyleFull / UIImmersionStyleProgressive nested in the scene configurations dictionary under UISceneSessionRoleImmersiveSpaceApplication. Note: There's also UISceneSessionRoleImmersiveApplication without the Space part. Make sure to use the right one in both places. I used Xcode's GUI to set it up, but here's the working Info.plist as of Xcode 15.0 beta 8 (15A5229m): <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>UIApplicationSceneManifest</key> <dict> <key>UIApplicationPreferredDefaultSceneSessionRole</key> <string>UISceneSessionRoleImmersiveSpaceApplication</string> <key>UIApplicationSupportsMultipleScenes</key> <true/> <key>UISceneConfigurations</key> <dict> <key>UISceneSessionRoleImmersiveSpaceApplication</key> <array> <dict> <key>UISceneInitialImmersionStyle</key> <string>UIImmersionStyleProgressive</string> </dict> </array> </dict> </dict> </dict> </plist>

SwiftUI views in visionOS can be presented as windows via the openWindow enviroment action and as RealityView attachments. Your VideoView is presented as neither. An ImmersiveSpace doesn't know where to put a SwiftUI view on its own in the unbounded full space. Note that if you go for an attachment, be wary of the recent API changes which seem to be currently undocumented.