Summary We have identified a reproducible world tracking drift regression in ARKit on LiDAR-equipped iOS devices running iOS 26.4 and later. A static virtual node anchored at the world origin visually drifts from its initial position as the user moves around a real-world scene, despite the scene remaining physically static. The same code produces stable, drift-free results on non-LiDAR devices running identical OS versions. Device & OS Observations Testing was performed across four devices on iOS 26.4 using the same application build and ARWorldTrackingConfiguration settings. Non-LiDAR devices — iPhone 14 and iPhone 15 — produced stable, drift-free tracking in all test runs. No world origin displacement was observed regardless of how long or how far the user walked. LiDAR-equipped devices — iPhone 14 Pro and iPhone 16 Pro — exhibited consistent, reproducible drift. A static node placed at the world origin visually shifted from its initial position as the user moved through the scene. The same devices were stable on earlier iOS versions, confirming this is a regression introduced in iOS 26.4. Technical Observations Nature of drift: A SCNNode placed statically at the ARKit world origin (SCNVector3(0, 0, 0)) visually displaces from its original position as the user walks around a static real-world scene. The displacement is not random — it accumulates directionally as the user moves, consistent with a sensor fusion or coordinate anchoring error. Trigger condition: The drift occurs during normal walking motion around a fixed point of interest, such as circling a parked vehicle. It does not appear when the device is held still. LiDAR specificity: The drift is exclusive to devices with a LiDAR scanner. Identical hardware configurations — same iOS build, same ARWorldTrackingConfiguration settings — on non-LiDAR devices produce no drift whatsoever. This isolates the regression to the LiDAR sensor's contribution to ARKit's internal Visual-Inertial Odometry (VIO) fusion pipeline. No API-level workaround found: There is currently no public ARKit API to selectively disable the LiDAR scanner's contribution to VIO. All available configuration-level options have been evaluated without resolving the drift. ARWorldTrackingConfiguration Options Evaluated The following configuration changes were applied individually and in combination. None resolved the drift on LiDAR devices: isAutoFocusEnabled = false — No improvement videoHDRAllowed = false (disabled) — No improvement planeDetection = [] (disabled) — No improvement sceneReconstruction = .mesh — No improvement worldAlignment: .gravity vs .gravityAndHeading — No improvement Minimal Reproduction Case The drift can be reproduced with a minimal ARKit scene: Create an ARSCNView with ARWorldTrackingConfiguration using default settings. Add a single static SCNNode (e.g., a small sphere or axes geometry) at SCNVector3(0, 0, 0) when the session starts. Run the app on a LiDAR-equipped device (iPhone Pro, iPad Pro with LiDAR) on iOS 26.4 or later. Walk in a circle around the node's approximate real-world position. Expected: The node remains visually fixed at its world position throughout the walkthrough. Actual: The node drifts from its initial position, increasingly displaced from its world origin anchor as walking continues. We want to know if Apple has made any internal updates to ARKit, particularly after the OS 26.4 upgrade. Thanks!

I have been building a visionOS app that converts anaglyphs and SBS to 3D experiences, and my current approach has been hamstrung by my dependency on a shader graph which separates imagery into right and left eye. It works very well, but ultimately is just a material. The way I have implemented this so far is with VNC to show a 3d Blender window and browser experiences. Ideally, I'd be able to have interactivity in both that didn't depend on an attached computer. Is there any way to accomplish that?

As the title says. I am developing an app for IOS 18, which involves adding a building relatively far away from the user's place (around 10-20m.), and I need to building to show contact shadows with the floor for added realism. Now, I know that RealityKit has automatic contact shadows using GroundingShadowComponent, but this only works if the object is placed in a plane that has been detected by ARKit... and ARKIt doesn't detect floors so far away, so I need to add my own shadows: add an invisible plane acting as a floor below my building, and have it receive shadows and show only the shadows. The problem is that, from what I see, RealityKit has no materials that can do this: UnlitMaterial ignores all lighting, including shadows. SimpleMaterial does display the shadows, but the floor is displayed too. I can make the material almost transparent (setting the opacity to 0.01 or something), but the floor is still visible. OcclusionMaterial with receiveDynamicLighting is a solution, but it doesn't work either. If I declare it using OcclusionMaterial(receivesDynamicLighting: true), all I get is an invisible plane with no contact shadows in it. What do other people do for this? Do people just bake in the contact shadows in the 3D model?

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.

Dear Apple Developer Team, I would like to ask a few questions related to RoomPlan, Room API, USDZ export, and possible future spatial scanning workflows: Can the RoomPlan or Room API load an existing USDZ room model and compare it in real time with a new live scan of the same space? Is Apple considering extending RoomPlan beyond indoor rooms, for example to scan outdoor areas, house exteriors, terrain, and simple building volumes with rough dimensions? Also in indoor to scan slopes with angle room for rooms in roof floor? Will RoomPlan support multi-floor continuous scanning, custom object detection elements, and reliable export of the scanned result to USDZ for further CAD/BIM workflows? Is it possible to create a real-time comparator between a reference object in USDZ or STEP format and a physical object being scanned live, so that deviations in geometry or dimensions can be detected during scanning? Best regards, Ivo Saina

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?

In visionOS 26 (with Website Environments enabled), there was a two step action to enable the environment: click button on the left of the address bar (1 in image), then click "Open Website Environment" (2 in image). This example was shown again this year in Build next-generation experiences with visionOS 27. But I do no see this working in visionOS 27. Instead, I've needed to add a button for the user to open (and optionally close) the website environment. Is adding a button/control to the web page the new way to activate website environments?

Good Morning! Following the RCP 3 lightmap workflow: I've added Lightmap components to my entities and hit Bake, but I get "Lightmap bake failed: no lightmappable entities found — enable Process for Lightmaps in an asset's Geometry Transform Settings." I can't locate that flag anywhere in the GUI, and my scene objects are prototype instances. Could you walk through the complete end-to-end setup for baking lighting: where the Process for Lightmaps flag actually lives (on the instance or the source asset?), whether lightmap UVs must be authored or are auto-generated, and how the Lightmap component relates to that eligibility flag?

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.

Hi, several WWDC26 sessions this year feature the Chaparral Village project. However, I can't find a download for it anywhere. Will the Chaparral Village project be published as downloadable sample code? Thanks!

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?