visionOS RealityView attachment SwiftUI controls don't always respond to user interaction

My visionOS app has a RealityView with an attachment containing SwiftUI controls, and occasionally the controls in the attachment don't respond to user interaction.

Is this a known issue?

Is there a workaround?

Are RealityView attachments only intended to be output only?

Using visionOS 1.0 beta 3 (Xcode 15 beta 8), I've reproduced this problem with a small standalone Xcode project. I submitted the issue as FB13143132 with lovingly hand-crafted artisan repro steps. The Xcode project is also available at https://github.com/drewolbrich/AttachmentControls

Thank you for investigating this issue.

Screenshot my use case:

Up vote post of hhjgjhghjghjghjg Down vote post of hhjgjhghjghjghjg
1.7k views
Posted by
hhjgjhghjghjghjg
Reply
Add a Comment

Accepted Reply

This was fixed in visionOS 1.0 beta 4.

Posted by
hhjgjhghjghjghjg
Up vote reply of hhjgjhghjghjghjg Down vote reply of hhjgjhghjghjghjg
Post marked as solved
Add a Comment

Replies

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.

Posted by
atbf
Post not yet marked as solved Up vote reply of atbf Down vote reply of atbf
Add a Comment

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.

Posted by
atbf
Post not yet marked as solved Up vote reply of atbf Down vote reply of atbf

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

    —
    hhjgjhghjghjghjg

  • You're welcome! When you say, you update the attachment, I assume this means RealityViewAttachments doesn't change, but the respective attachment entities get added to RealityViewContent for the first time? In case another delay doesn't help, maybe it is necessary to add all attachment entities in the make closure at once and then show and hide them as needed. That would be an ugly solution, but it's all a hack anyway right now. I hope, we're going to see another beta with a fix soon.

    —
    atbf

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

    —
    hhjgjhghjghjghjg

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.

Posted by
hhjgjhghjghjghjg
Up vote reply of hhjgjhghjghjghjg Down vote reply of hhjgjhghjghjghjg
Add a Comment

@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. ❤️

Posted by
hhjgjhghjghjghjg
Post not yet marked as solved Up vote reply of hhjgjhghjghjghjg Down vote reply of hhjgjhghjghjghjg

  • Thank you, glad to hear it! I never received any response to my visionOS related bug reports, so it's good to know that Apple are reacting to our feedback.

    —
    atbf

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

    —
    hhjgjhghjghjghjg

  • 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. 🤪

    —
    hhjgjhghjghjghjg

This was fixed in visionOS 1.0 beta 4.

Posted by
hhjgjhghjghjghjg
Up vote reply of hhjgjhghjghjghjg Down vote reply of hhjgjhghjghjghjg
Post marked as solved
Add a Comment