Foveated Streaming & Spatial Tracking Q&A

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 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!

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?

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?

Hello, and thank you for taking questions this week. We develop DeepWalk, a production App Store application that captures LiDAR depth, RGB, and ARKit camera poses while field technicians walk continuous outdoor routes (sidewalk and infrastructure assessment). Recorded ARCamera.transform values are used downstream for 3D reconstruction, so world-tracking accuracy directly determines our output quality. Problem: Beginning in early April 2026 and coinciding with the iOS 26.4 rollout across our device fleet, we observe directional, accumulating pose drift in recorded trajectories during normal walking motion. The behavior matches the regression reported in forum thread 827240 (world-tracking drift on LiDAR devices on iOS 26.4+, absent on non-LiDAR devices running identical code). Link to existing post here: https://developer.apple.com/forums/thread/827240 Our configuration is minimal: a default ARWorldTrackingConfiguration with frameSemantics = [.sceneDepth, .smoothedSceneDepth] and no other options set, running on a bare ARSession with a Metal renderer (no SceneKit/RealityKit). We measure drift directly from per-frame ARCamera.transform values, so the displacement appears in ARKit's pose output itself rather than in any rendering layer. The drift accumulates with walking distance and does not occur when the device is stationary. We've observed this across a large variety of devices (iPhone 15/16/17 Pro/Pro Max) on all iOS versions 26.4 or greater. We've also observed this on iPad Pros with updated firmware. Thread 827240 additionally reports that disabling autofocus, HDR, and plane detection and varying scene reconstruction and world alignment did not resolve it. Question Because depth capture is our core function, we cannot avoid engaging the LiDAR scanner, and we're not aware of a public API that adjusts its contribution to world tracking. We'd be grateful for guidance on three questions: Is this a known issue in iOS 26.4 and later? Did the LiDAR contribution to world tracking change in that release? For apps that require sceneDepth, is there any recommended session configuration, video format, or capture-side practice that reduces the drift in the interim? Is a fix planned, and if so, should we expect it in an iOS 26.x update or the iOS 27 cycle? This affects how we manage our deployed device fleet. We're happy to provide trajectory datasets, additional sysdiagnoses, or anything else useful. We have quantified drift-per-distance data across OS versions.