Does your application start with the CompositorServices ImmersiveSpace? Yep, I have an ImmersiveSpace whos content is created using Compositor Services. Regarding the plist, I had exactly that and I am getting a black background with no passthrough. Also in the ImmersiveSpace you will need to set the style to mixed. This is how you would set it to be always mixed: Yep I have that set too.

Interesting, I'll try that out. Thank you.

Simulator

MTKView was added recently to visionOS 1.0+ but I can't get it to work on anything before visionOS 2.0 beta. See my post here: https://developer.apple.com/forums/thread/759029

Hello Sydney, Thank you for the response. I forgot to add that there is a metal view involved in this app and that could be another reason why this problem occurs. I have some simple code here that shows the problem. Can you give this a test? You will notice that the gesture only gets recognized about half the time. struct ContentView: View { var body: some View { MetalView() } } struct MetalView: UIViewRepresentable { var device: MTLDevice? init() { self.device = MTLCreateSystemDefaultDevice() } func makeUIView(context: Context) -> MTKView { let mtkView = MTKView() mtkView.device = device mtkView.clearColor = MTLClearColor(red: 0.0, green: 0.0, blue: 0.0, alpha: 1.0) mtkView.delegate = context.coordinator // Add tap gesture recognizer let tapGesture = UITapGestureRecognizer(target: context.coordinator, action: #selector(context.coordinator.handleTap(_:))) tapGesture.numberOfTapsRequired = 1 // Should require both hands to tap. tapGesture.numberOfTouchesRequired = 2 mtkView.addGestureRecognizer(tapGesture) return mtkView } func updateUIView(_ uiView: MTKView, context: Context) { } func makeCoordinator() -> Coordinator { Coordinator(self) } class Coordinator: NSObject, MTKViewDelegate { var parent: MetalView init(_ parent: MetalView) { self.parent = parent } func mtkView(_ view: MTKView, drawableSizeWillChange size: CGSize) { } func draw(in view: MTKView) { guard let drawable = view.currentDrawable else { return } guard let descriptor = view.currentRenderPassDescriptor else { return } let commandQueue = parent.device?.makeCommandQueue() let commandBuffer = commandQueue?.makeCommandBuffer() let renderEncoder = commandBuffer?.makeRenderCommandEncoder(descriptor: descriptor) renderEncoder?.endEncoding() commandBuffer?.present(drawable) commandBuffer?.commit() } @objc func handleTap(_ sender: UITapGestureRecognizer) { print("MTKView tapped") } } } I'm happy to submit a feedback report but I'm curious what your feedback is when you see the issue. Thank you!

Feedback number -> FB14442495

Thanks for the response! We aren't using any of those methods hence why I was confused.

Thank you for confirming! I look forward to hearing back from either here or the feedback report.

Nope. I just installed visionOS 2 beta on the device and I'm using Xcode 16 beta. And I no longer see that issue with that combo.

Thank you Sydney. That makes sense. Since the text is getting cut off in the simulator and there is no safe area insets for a window, is there a way to calculate the correct padding so the text isn't cut off? Rather than just using some hard-coded values for the padding.

It does work and doesn't look too bad. But if we wanted to add some custom padding to make it look exactly how we wish it wouldn't be possible because we don't know how a user would use our views and that could change how this bottom bar looks. We work on a native Swift SDK to add some context. So the user could use our view in a 2D window, 3D window, in a 2D window but as a subview, etc. And we don't have a way of knowing how to adjust our padding because there is no concept of safe area. I'm not sure if this is deliberate or not but if you have any context on that it would be great. Thank you again for the quick responses :) Here is what the bottom bar looks like in different contexts: 2D Window: 3D Window: 2D window but with another view

I'll give the ornament a shot. I didn't even consider that in the beginning because it seems like they are more meant for interactions with the view while this bar is simply meant to display copyright information about the data that is being presented. While the bar can be interacted with, that isn't its main goal. But hey I can give it a shot and let you know if I have more questions. Thank you for your help.

I just ran a visionOS 1.2 simulator that uses a MTKView with Xcode 16 beta 4 and it no longer crashes.

Updated the original post: If you replace the MetalView() simply with EmptyView() it still shows a memory leak.

That is good to know. I actually wanted the body of the if to be executed for visionOS but didn't understand why it was working. Thank you. Can you explain why this situation crashes? Also, I had this similar code that was distriubted via a xcframework and when that view is used in an app that is using the xcframework while running against visionOS there would be a runtime crash (EXC_BAD_ACCESS). The crash could only be reproduced when using that view from the xcframework and not the local source code. The problem was fixed by adding visionOS 1.0 to that availability check. But this shouldn't have been a crash in the first place.