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.

Ok trying to play Spatial Audio on my VisionPro. OS26.4, using Xcode 26.4.1. Every attempt gives me the following error. <<<< FigAudioSession(AV) >>>> signalled err=-19224 at <>:612 I have tried the sample code at https://developer.apple.com/documentation/visionos/playing-spatial-audio-in-visionos and it gives the same error.

I'm shipping a PCVR streaming app using PSVR2 Sense controllers on the Vision Pro. Four pain points I'd love clarity on: PSVR2 L3/R3 thumbstick click at rest — Apple's GameController framework doesn't fire a stick-click event unless there's axis deflection. Users physically clicking the stick straight in get nothing. Is this an intentional filter, and is a change planned? Haptic forwarding PC → AVP. On CloudXRKit there's NSKStreamClientHapticDelegate for dispatching server-generated haptic events into CHHapticEngine. Does FoveatedStreaming have an equivalent delegate, or are streamer apps expected to bring their own side-channel for haptics? Controller pose — we're currently going through ARKit's AccessoryTrackingProvider and combining with GCController input. Is that the recommended supported path for FoveatedStreaming apps, or is there something more native to the framework planned? Gaze clarity :- The framework already uses gaze internally to drive foveation tile selection on the server. Is any per-frame metadata returned to the client that tells us — even loosely — where the user is looking? A gaze quadrant, a foveal-tile coordinate, distance-from-fovea-centre. Anything we can feed back to the PC to tune its own pipeline. Privacy-preserving aggregates — would Apple consider exposing fixation/saccade ratios, gaze stability over the last N frames, dwell-on-region signals? Lets apps push higher detail without ever learning raw direction. 3. What's the actual barrier — strictly privacy, or also performance? If it's privacy, would an on-device processing surface (App Intent style, Background Asset extension, etc.) be a viable path to let apps act on gaze without raw access? 4. are there public APIs in this area today that I've missed? I've been working from the swiftinterface + WWDC sessions and don't want to be reinventing something that already exists in a quieter corner of the SDK.

Hello is a FovMutable implement is planned? it should be nice for pcvr gaming. Thanks

Hello! I am relatively new to dev for Apple Vision Pro, however I have owned one since launch and love it. When I heard that we were going to be able to preview real-time, 3D models from the Mac I couldn’t believe it! This is one of my major workflows and I have been using 3rd party workarounds (that don’t work well). My question is, is there any word on supported 3D modeling apps like Blender or Cinema 4D? Or will there be a way to implement this preview feature with any app via a protocol? Any documentation would be really helpfu! Thank you, and continue the great additions to Apple Vision Pro!

Hello there, I have a question and a potential solution to how these data could be opened to people developing streamers for foveated encoding. Is there any plans to open up any type of gaze data, be it exact or just a general area instead of a pinpoint? And if so I have a solution in mind, There could be a program for developers who are specifically making streaming apps in which Apple can come in and take a look at the streaming app and make a judgment from there if the developer would be trustworthy to allow access to gaze data. This would solve any privacy concerns regarding data scraping if the app was looked through beforehand while still enabling access to the needed data for foveated streaming. And beforehand there could be a prompt asking if you would like to allow the app to access gaze data or not much like other solutions. More developers of VR streaming apps having access to this would be a net positive thing as it would create more robust options to stream VR to The vision pro, as cloud XR is relatively limited in terms of what it supports. In turn it would create more incentive for more developers to develop their streaming solutions for the vision pro. Thank you for hosting this q&a!

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.

I want to: Run ARKit on the main rear camera, and while it's running shoot high resolution pictures on the wide camera, without disturbing the AR tracking. Is this possible?

I’ve seen, mainly in discussions with AIs, that ARFaceTrackingConfiguration uses the same technology as Face ID and therefore should work in complete darkness. However, I haven’t been able to achieve this. Does anyone know if this is actually true? I'm using an iPhone 16 to test, and the Face ID works well in darkness.

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.

M4 iPad Pros only have a single camera rear camera, are the older iPad Pro models assisting the tracking with the ultra-wide camera? We noticed that a AR Session recording records all rear and front cameras, but covering the ultra-wide doesn't impact the tracking in our testing. Would a partial cover (at the corners not the center) of the ultra-wide lens POV impact the tracking as well?

What are the best practices for import from Blender? I have a material that looks beautiful in Blender, but my attempts at migrating it to Reality Composer Pro had very poor results. An image of the nodes making up the material is attached, along with a rendering from Blender and RCP.

SceneKit was perfect to import 3D assets directly into our app scene. Since it's soft deprecation and the coming out of RealityKit, tutorials or documentation on how to bridge old possibilities are missing, everything seems to be about AR. More specifically, I am not able to find any resources on how to create a scene, load 3D assets, add a light and a camera, and everything within the app itself. No augmented reality. Is it intended to add some support about this? Any guidance would be appreciated.

Currently, I have a very basic entity in RCP that I call in my app's immersive view based on an included Package. I'm trying to get a much better 3d asset to use in my app instead. I've been afraid to put much effort into learning Blender to create and export an USDx asset for import into RCP3 (it's a whole world of learning itself...). I may be able to start using agents like Codex tied into Blender to see if I can more quickly create a 3d asset. I tried using the new AI assistant in RCP3 and it seems like I could create a 3d entity, but I'm not sure it will be the level of detail I want. Any high-level advice for the workflow (nowadays with AI agents) to create a desirable 3d asset, get it into RCP3, and then into Xcode?

Hello, I would like to inquire about recommendations regarding the performance overhead of VDB simulation on the M5 Vision Pro. Additionally, I would like suggestions for the best implementation for simulating rivers, waterfalls, snowflakes, and flames.

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.

When not sunny in outdoor environments during an ARKit session, captured frames often suffer from motion blur due to automatically selected longer shutter speeds. What are the best practices for prioritizing faster shutter speeds to reduce motion blur? Are there specific APIs or recommended configurations to safely balance the low-light/shutter speed trade-off without disrupting tracking?

I'm building an iOS game with RealityKit + Reality Composer Pro and was hoping to migrate to Reality Composer Pro 3. I created a new project in RCP and used the "link a new xcode project" flow. It built and rendered correctly on iOS 27. However, I encountered two issues when trying to build for iOS 26. The new RealityKitScripting package threw an error indicating <iOS 27 is not supported. I removed the related code, as I do not intend on using any Script Graphs. The iOS 27 scene still loaded correctly after removing this package. Are there any other consequences to removing this package other than not being able to use Script Graphs? Once the scene loading was working on iOS 26, I noticed that no materials built with the Shader Graph would render. Unlit and Physically Based materials render correctly, but Shader Graph materials do not. Even a simple Shader Graph with one Unlit material node input would not work. Is this expected behavior? My main question is, should I not expect to be able to use Reality Composer Pro 3 if I'm going to target an OS version <27?

Is there a supported route to automated regression testing of ARKit apps? Reality Composer's "Record AR Session" plus Xcode's "ARKit Replay data" scheme option work well for manual debugging, but replay isn't wired into XCUITest, doesn't run in CI, and ARKit doesn't exist in the simulator — so every AR regression today needs to be run by a human holding a device. Even replay-driven ARSession in the simulator, or an XCTest hook for selecting replay files, would unlock some automated coverage.

Is the website environment feature available on this first visionOS 27 beta? I am having troubles converting a web page that used the visionOS 26 website environment approach to the new visionOS 27 approach. Before I keep working on it, I would like confirmation that the feature is working. Also, does Apple have any web pages featuring a website environment that I can inspect?