Is a volumetric window recommended for menus in 3D-focused visionOS apps?

Question

Created 1d

Replies 4

Boosts 1

Participants 2

This post is from the WWDC26 3D Content Q&A.

For a visionOS app whose main content is 3D, such as a game or immersive experience, is it recommended to use a volumetric window as the main menu or in-game menu?

I’d like to understand the intended use cases for menus built as volumetric windows.

Specifically:

What are the advantages of using a volumetric window for menu UI compared with a regular 2D window or an in-scene SwiftUI attachment?
What limitations should developers be aware of, such as fixed size, placement behavior, lighting separation, interaction comfort, or window management?
For a 3D game-like app, is a volumetric menu generally considered a good visionOS design pattern, or should volumetric windows be reserved for 3D content rather than menu-heavy UI?

Any guidance on the recommended design approach would be appreciated.

Answered by Vision Pro Engineer in 892551022

Hey @Sakuya_Izayoi,

Thanks for your question. Quoting the Human Interface guidelines, "Prefer using a volume to display rich, 3D content. In contrast, if you want to present a familiar, UI-centric interface, it generally works best to use a window."

I'd love to know a little bit more about what you are thinking about. Volumetric windows are best for contents that fill the depth of the volume. If you have flat content, presenting this with a normal window or embedded in the scene using a ViewAttachmentComponent is usually the best approach. Why are you considering using a volumetric window rather than a standard window?

You might consider taking some inspiration from our sample code projects:

Hello World launches as a normal window, and opens a volumetric window to show the globe. This volumetric window includes an ornament to configure the options for the globe. When the user launches the immersive space for the solar system a window provides additional context to the user using the approached outlined in this sample code.
Petite Asteroids launches as a volume, with navigation embedded within the scene using ViewAttachmentComponent. An ornament is also used to provide consistently visible settings.
Canyon Crosser launches as a volume, allowing the user to select a location to explore from a 3D carousel.

Let me know if you have additional questions,
Michael

Answer 1

Vision Pro Engineer OP

Apple

1d

Accepted Answer

Recommended

Hey @Sakuya_Izayoi,

Thanks for your question. Quoting the Human Interface guidelines, "Prefer using a volume to display rich, 3D content. In contrast, if you want to present a familiar, UI-centric interface, it generally works best to use a window."

I'd love to know a little bit more about what you are thinking about. Volumetric windows are best for contents that fill the depth of the volume. If you have flat content, presenting this with a normal window or embedded in the scene using a ViewAttachmentComponent is usually the best approach. Why are you considering using a volumetric window rather than a standard window?

You might consider taking some inspiration from our sample code projects:

Hello World launches as a normal window, and opens a volumetric window to show the globe. This volumetric window includes an ornament to configure the options for the globe. When the user launches the immersive space for the solar system a window provides additional context to the user using the approached outlined in this sample code.
Petite Asteroids launches as a volume, with navigation embedded within the scene using ViewAttachmentComponent. An ornament is also used to provide consistently visible settings.
Canyon Crosser launches as a volume, allowing the user to select a location to explore from a 3D carousel.

Let me know if you have additional questions,
Michael

Answer 2

Sakuya_Izayoi OP

1d

The reason I considered using a volumetric window for the menu is that the current defaultWindowPlacement APIs for regular 2D windows do not seem to provide a way to replace a 2D window with volumetric content in the same spatial position.

For that reason, I was thinking that if both the menu and the 3D content lived inside the same volumetric window, the transition from menu UI to 3D content could feel more natural and avoid the placement jump between a 2D window and a volume.

Answer 3

Vision Pro Engineer OP

Apple

1d

Thanks for that additional info @Sakuya_Izayoi,

If you were replacing the window with another window you could use pushWindow. However, this API is not available to push a volume. I'd greatly appreciate if you could file an enhancement request using Feedback Assistant for this functionality. If you're not familiar with how to file enhancement requests, take a look at Bug Reporting: How and Why?

Could you provide me with more context of the information provided by the menu and your content?

In Hello World, the menu window is kept around when the volumetric globe is opened. Does it make sense for your experience to have both of these scenes open at the same time?

In Petite Asteroids, the application launches to the first scene of the game with a menu shown open top of it. This provides a great immersive experience giving the user a taste of what they'd expect once they start the game. Would your experience benefit from any spatial content that you could present inside the volume alongside the menu?

In Canyon Crosser, the loading view, carousel view, and the hiking view are provided within the same volume. You could use a similar approach if you needed to switch between your views. Watch Meet SwiftUI spatial layout to understand more about this type of spatial layout.

Thanks!
Michael

Answer 4

Sakuya_Izayoi OP

1d

Thanks for your infos. I'll file an enhance request and provide more infos about my app in the request. For my app, if the pushwindow api could support volume that'll be perfect. Interestingly, if user open immersive space in my app, I could precisely control the placement of 3d content after the menu window closed.