Also, instead of killing the app from the Terminal which requires tricks like ps -e | grep MyAppName.app to find the process ID, you could use ⌘Q via the simulator's passthrough mode.

Thank you for posting this. : - )

Maybe I could wrap the UIView in a UIViewRepresentable wrapped in a UIHostingController wrapped in a delicious tortilla.

Thank you @sha921

@atbf Thank you, that works great for me in Xcode 15.0 beta 8.

I've filed 16 visionOS bugs so far and this is the only one that's gotten a response from a human. I think I got a response to this one because I posted lots of followup comments with more details over a period of a week, giving it lots of attention, and then I posted a comment specifically asking if anyone was reading them and requesting a response. 🤪

They also wrote "Unfortunately, we know that it sometimes not getting a timely response may feel like your report goes unseen, but please know that every bug report submitted by a developer is read by and responded to by a real person." I don't think "responded to by a real person" literally means that they type a comment or that you see any actual visible indication of a response, but this sounds reassuring. An Apple engineer I know also told me that all of them eventually get read.

@mesqueeb I found out about the Attachment(id:) fix on the Apple Vision Pro Discord https://discord.gg/D8jf4anD On the #developer channel, we spent an hour trying to figure why attachments no longer worked in the new Xcode beta, and one of the developers happened to type Attachment and got lucky with Xcode autocomplete.

Again, thank you so much for you suggestion. Your workaround makes continued development so much more tolerable. I will teach my children to sing songs in your honor.

Your original solution works most of the time in RealityView/make but I still experienced unresponsive SwiftUI attachment controls if I updated the SwiftUI view later. I was eventually able to work around this by adding a debug option to tear down my RealityView completely and recreate it it, which re-executes the make closure with your awesome fix, and I can use this as a workaround until Apple fixes this issue.

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.)

Thank you, this is a wonderful find. I did a quick test and it seemed to work although I'd have to do more testing to make sure. However, it only works for the first set of controls my app displays. If I later update the attachment to display a different set of controls, I still see the same issue. I have to run off now but I'll give this more thought. Maybe I can introduce a delay when the controls view is updated later, and that'll also work. But, this is a wonderful clue. You are amazing.

Thank you for responding. That is interesting to know, although it doesn't help in my case, where 3D is required. I have also filed this question as feedback, as FB12242527 with additional details.

I KISS YOU