I’m building a visionOS app that starts with a regular 2D SwiftUI window. From that 2D window, the user can enter a volumetric mode, where I want to open a large volumetric WindowGroup and have it appear centered around the same spatial position as the original 2D window. The volumetric window is physically large, roughly over 1m × 1m × 30cm. Because of that, placement behavior is very noticeable. My intended behavior is: User is interacting with a regular 2D window. User taps a button. A large volumetric window opens. The volumetric window appears in front of the user, ideally centered on or near the original 2D window’s position. The original 2D window is dismissed or replaced. My current workaround is to call openWindow(id:) for the volumetric window, then dismiss the original 2D window. This works in the sense that the volume is created, but its initial position is noticeably offset from the original 2D window. I also tried using defaultWindowPlacement to control the placement of the volumetric window relative to the existing 2D window. I tested placements such as .below, .trailing, and other relative positions. However, because the volumetric window is large, the result is worse: when I open the volume from the 2D window, the volumetric window appears to move instantly far away from the user’s view, almost as if it flies out of the visible workspace. After that, I can no longer see or interact with the volume. Interestingly, if I then go back to the system Home View and tap the app icon again, the volumetric window appears normally in front of the user. Here is a simplified version of my setup: @main struct MyApp: App { var body: some Scene { WindowGroup(id: "main") { MainWindowView() } WindowGroup(id: "volume") { VolumeView() } .windowStyle(.volumetric) .defaultSize(width: 1.0, height: 1.0, depth: 0.3, in: .meters) // I also tried defaultWindowPlacement here, // using placements such as .below, .trailing, etc. } } struct MainWindowView: View { @Environment(.openWindow) private var openWindow @Environment(.dismissWindow) private var dismissWindow var body: some View { Button("Open Volume") { openWindow(id: "volume") dismissWindow(id: "main") } } } What I would like to know: Is there a supported way to open a large volumetric window from a 2D window while preserving or approximating the 2D window’s spatial center? Is defaultWindowPlacement expected to work reliably for large volumetric windows, or can relative placements such as .below or .trailing cause the volume to be placed outside the user’s comfortable visible area? Is there any API that exposes the current 2D window’s spatial position or center so I can place the volumetric window more precisely? Can pushWindow(id:) be used to replace a 2D window with a volumetric window while preserving placement, or is this transition not currently supported? Why would the same volumetric window appear far away when opened from the 2D window, but appear normally in front of the user when the app is reopened from the system Home View? What is the recommended UX or technical pattern for transitioning from a regular 2D window into a large volumetric window without the volume jumping or appearing outside the user’s view? I’m testing this on: visionOS version: [26.5] Xcode version: [26.4.1] Device or Simulator: [vision pro m2 & m5] SwiftUI app lifecycle Source scene: regular WindowGroup Destination scene: WindowGroup with .windowStyle(.volumetric) Approximate volume size: over 1m × 1m × 30cm Any guidance on the recommended placement strategy for large volumetric windows would be appreciated.

I have a question about user-controlled movement inside a visionOS ImmersiveSpace. If an app allows the user to move through a virtual space, what are the recommended ways to reduce motion sickness or discomfort? Specifically: Are there recommended movement speed limits for comfortable locomotion in an immersive space? Are there recommended acceleration, deceleration, or turning speed limits? Is snap turning generally preferred over smooth turning on visionOS? Are teleportation, short-range movement, or fixed-position interaction recommended over continuous movement? Are there any visionOS-specific comfort guidelines for camera movement, artificial locomotion, field-of-view reduction, or user-controlled navigation? My goal is to allow limited movement in an immersive environment while keeping the experience comfortable for most users.

I have a question about using HDR visual content in visionOS, especially inside a volumetric window or an ImmersiveSpace. For example, if I display an HDR photo or use very bright lighting on reflective materials, I can sometimes trigger a noticeably higher peak brightness on Vision Pro. However, in my testing, this higher brightness only lasts for a short time. After that, the overall scene brightness appears to be reduced automatically. I would like to understand the intended behavior and recommended usage pattern. Specifically: Is HDR image content recommended for use inside volumetric windows or immersive spaces? Are HDR photos or high-brightness reflective highlights intended mainly for short-duration local highlights rather than sustained full-scene brightness? Does visionOS apply automatic brightness, tone mapping, thermal, or power-related management when immersive content contains very bright HDR areas? Are developers expected to avoid large or sustained high-brightness HDR content in immersive scenes? What is the recommended way to author HDR images, bright highlights, emissive materials, or reflective materials so they look realistic without causing the whole scene to dim? Are there any visionOS-specific guidelines for HDR content, peak brightness, average scene brightness, or comfort when presenting HDR photos or bright 3D materials? My goal is to use HDR content responsibly for realistic highlights, reflections, glass, metal, or photo display, while avoiding visual discomfort or unexpected global dimming behavior. Any guidance would be appreciated.

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.

I have a question about rendering performance guidelines for visionOS ImmersiveSpace. Since visionOS uses foveated rendering, why are polygon count and scene complexity still treated as strict performance constraints for immersive content? My understanding is that foveated rendering reduces rendering cost outside the user’s central field of view. If so, should polygon count mainly matter near the gaze/foveal region, while objects in the peripheral area are much cheaper to render? Specifically: Does foveated rendering reduce only pixel shading cost, or does it also significantly reduce geometry processing cost? Are polygons outside the foveal region still submitted, culled, transformed, and rasterized in a way that affects CPU/GPU performance? For large immersive environments, should developers still optimize total scene polygon count, or focus mainly on what appears near the user’s gaze? Are there recommended guidelines for LOD, culling, and polygon budgets in visionOS immersive spaces, even when foveated rendering is enabled? I’d like to better understand how foveated rendering affects geometry budgets, and how developers should think about scene complexity for immersive visionOS apps. Any guidance would be appreciated.

I’m using Reality Composer Pro 3 for a visionOS project, and I have a question about the editability of Shader Graph and other node-based systems. In RCP, Shader Graphs and other node graphs can be created and edited visually in the editor. I would like to know whether these graphs also have a supported code-based or text-based editing workflow. Specifically: Is there a public, documented file format for Shader Graphs in Reality Composer Pro 3 that developers can edit directly outside the RCP GUI? Can Shader Graph nodes, connections, parameters, and materials be generated or modified through code, scripts, or text files in a supported way? Does the same apply to other node graphs in RCP, such as behavior graphs or animation-related node graphs? If these graphs are stored internally inside the Reality Composer Pro project package, is it safe or supported to edit those underlying files directly? If direct editing is not supported, is there any recommended workflow for version control, reuse, templating, or programmatic generation of similar Shader Graph setups across multiple assets? My reason for asking is that I’m trying to build a more scriptable asset pipeline. For models and scene structure, it is often practical to generate or modify content through code. However, for complex Shader Graphs or node graphs, manually rebuilding similar node setups in the GUI can become repetitive and difficult to maintain. I’m not asking about private or unsupported internal formats. I’d like to understand whether Apple currently provides, or recommends, any supported workflow for code-driven editing, generation, reuse, or version control of Shader Graphs and other node graphs in Reality Composer Pro 3. Any guidance would be appreciated.

I have a question about material authoring improvements in Reality Composer Pro 3, especially for transparent or refractive PBR materials. In Reality Composer Pro 2, I found it difficult to create convincing glass-like materials. For example, the available Shader Graph nodes seemed limited for this use case, and I could not find common controls or nodes that are often useful for glass and crystal materials, such as Fresnel-style effects or more direct refraction-related controls. I would like to understand whether Reality Composer Pro 3 has improved this area. Specifically: Does Reality Composer Pro 3 provide better support for realistic glass, crystal, acrylic, or transparent PBR materials? Are there new Shader Graph nodes or material controls that help with Fresnel-style edge reflections, angle-dependent transparency, or similar effects? Does Reality Composer Pro 3 support index of refraction / IOR controls for transparent or refractive materials? Is there any supported way to create real refraction or physically plausible transmission for glass-like materials in RCP 3? If true refraction or IOR control is not supported, what is the recommended approach for creating convincing glass, crystal, or polished transparent materials for visionOS apps? Are there any sample projects, documentation pages, or WWDC sessions that show the recommended material setup for glass-like surfaces in Reality Composer Pro 3? My goal is to create visually believable glass and crystal-style materials inside the standard visionOS / RealityKit rendering pipeline, preferably using supported RCP material tools rather than unsupported shader workarounds. Any guidance on the current capabilities and recommended workflow in Reality Composer Pro 3 would be appreciated.

If I open a regular 2D window or a volumetric window while the ImmersiveSpace is active, is there any supported way for that window or volume to receive lighting from the immersive scene? For example, if I have lights, environment lighting, or other lighting setup inside the ImmersiveSpace, can those lights affect the content of a 2D window or a volumetric window opened by the same app? Or are windows, volumes, and immersive spaces rendered with separate lighting contexts? I’d like to understand the recommended approach if I want UI panels or small 3D volumes opened during an immersive experience to visually match the lighting of the immersive environment.

I’m building a visionOS app with an ImmersiveSpace, and I want to show a menu or control panel inside that immersive space. The menu would be created as part of the app’s immersive content, for example as a SwiftUI attachment in a RealityView, or as a custom RealityKit entity with UI-like content. What I would like is for this in-space menu to behave more like a regular visionOS 2D window: The user can move the menu naturally. While the menu is being moved, it automatically adjusts its orientation to face the user. It maintains a comfortable apparent size or distance while being repositioned. It avoids awkward angles or unreadable placement. It feels similar to the system-managed behavior of regular 2D windows. My question is: is there a supported way to give an in-ImmersiveSpace menu the same placement and movement behavior as a normal 2D window? More specifically: Is there a built-in component or API that provides window-like movement, billboard-facing behavior, comfortable distance handling, or automatic scaling for custom panels inside an immersive space? If not, is the recommended approach to implement this behavior manually in RealityKit, for example by tracking the user’s head position and updating the panel’s transform? If manual implementation is required, are there recommended comfort guidelines for menu distance, scale, rotation limits, and movement behavior in immersive spaces? Alternatively, is the recommended design to use a regular 2D window or utility panel outside the immersive content, rather than trying to recreate window behavior inside the ImmersiveSpace?