Why is this still not supported on Apple Vision Pro? For a premium device that has been on the market for nearly three years and costs thousands of dollars, it's difficult to understand why Apple still hasn't provided a basic option to disable spatial anchoring when it isn't needed. This limitation becomes particularly frustrating in moving environments such as cars, buses, trains, airplanes, and cruise ships. Users have repeatedly reported issues with virtual windows drifting, shifting, becoming unstable, or losing tracking entirely. Apple introduced Travel Mode to address some of these challenges, but reports of tracking problems persist, and certain environments remain unsupported. Why should something as simple as watching a movie or using a virtual monitor require constant 6DoF spatial tracking? Not every use case requires a fully spatial experience. Sometimes users simply want a stable virtual screen without the operating system constantly attempting to anchor it to their surroundings. At a minimum, visionOS should provide three display options: 6DoF Spatial Mode: The existing experience, with windows anchored to the physical environment. 3DoF Rotation-Only Mode: Virtual screens respond to head rotation without relying on positional tracking. Head-Locked Mode: A screen remains positioned directly in front of the user without requiring environmental anchoring. Other headsets have offered simplified tracking options for years. It's disappointing that a product at this price point still lacks comparable flexibility. Users shouldn't have to struggle with spatial tracking just to watch a movie, browse Safari, or use Mac Virtual Display, particularly when the hardware is capable of delivering an otherwise excellent viewing experience. Apple Vision Pro has been available for nearly three years. Why is such a fundamental display option still missing? Is there an actual technical limitation preventing Apple from implementing this, or has it simply not been prioritized? At this stage in the product's lifecycle, this shouldn't remain an unresolved limitation. Apple should provide users with greater control over display tracking rather than forcing every use case into the same spatial computing model. I'd like to hear whether Apple has any plans to address this in future visionOS releases.

Hi, We build a PC VR streaming app for Apple Vision Pro. It has two VR paths: our own stream (our transport, VideoToolbox decode, our compositor layer) and FoveatedStreamingSession with CloudXR, which we use for titles that benefit from foveation. On our own path we filter the head and controller poses and send velocity. Getting both right took a lot of on-device tuning, and they made a large difference to comfort and to physics-based games. On the FoveatedStreamingSession path, the pose path from tracking to the endpoint runs inside the system, so an app has no way to apply, adjust or even inspect either one. We would like to ask for that control. 1. Pose smoothing for the head and controllers What we measured on device: Vision Pro tracking picks up very small, heartbeat-rate motion (around 1.2 Hz, millimetre scale). Locally that is invisible. After a streaming round trip it comes back as a visible world shake, because the remote frame is rendered at a pose about 50 ms old and reprojection has to cover the difference. Our A/B tests showed the tremor is largely rotational. Reprojection did not fully absorb it at our latency: turning off only the rotation filter brought the shake back right away. What fixed it for us: a One-Euro filter on the head pose, applied on the client before the pose is sent, with the frame anchored at the exact pose it was rendered with, so reprojection still covers the gap to the real head at no added latency. The values we settled on after live tuning: ComponentMin cutoffBetaPosition0.1 Hz12Rotation0.5 Hz12The right values depended on the content, the user and the end-to-end latency, which is why we are asking for control rather than one fixed default. Controllers need their own settings, because the right balance between lag and steadiness differs between fast games and precise work such as aiming or drawing. What we would like on FoveatedStreamingSession: Separate smoothing settings for the head and for tracked accessories, with position and rotation set independently. A choice of system default, off, or custom parameters. A One-Euro style minimum cutoff plus speed coefficient would cover our case. Documentation of what filtering, if any, the system applies today, so apps don't filter on top of it. 2. Velocity for the head and controllers Physics titles (throws, grab-and-pull, swings) take their motion from the linear and angular velocity in the OpenXR space velocity (XrSpaceVelocity), not from changes in position. If velocity arrives as zero, throws drop at the user's feet. If it arrives noisy, the PC runtime's own extrapolation to photon time amplifies the noise, and the controllers shake at rest. We hit both cases on our own path. What fixed them: Pass the accessory anchor's velocity through. Set the pose time offset from the client's own prediction, so the PC side does not predict twice. Apply a small deadband (about 0.05 m/s linear and 10°/s angular, matching common open-source streamers). What we would like on FoveatedStreamingSession: Documentation of whether linear and angular velocity are sent to the endpoint for the head and for tracked accessories, and in which reference frame. We could not find a frame statement for AccessoryAnchor velocity in the docs or the SDK interface. Game title testing appears as though these values not being sent. App control over velocity: on/off, a gain, a deadband, and a filter (or the same smoothing settings as above). The prediction offset the session uses when it sends poses, so apps and endpoints can avoid predicting twice. 3. A possible API shape (only a sketch to try to convey the requested need) extension FoveatedStreamingSession { struct PoseFiltering: Sendable, Equatable { static var systemDefault: PoseFiltering { get } static var off: PoseFiltering { get } static func oneEuro(positionMinCutoff: Double, positionBeta: Double, rotationMinCutoff: Double, rotationBeta: Double) -> PoseFiltering } struct VelocityReporting: Sendable, Equatable { var isEnabled: Bool var linearGain: Float var angularGain: Float var linearDeadband: Float // m/s var angularDeadband: Float // rad/s var filtering: PoseFiltering } var headPoseFiltering: PoseFiltering { get set } var accessoryPoseFiltering: PoseFiltering { get set } var accessoryVelocityReporting: VelocityReporting { get set } var posePredictionInterval: TimeInterval { get } }Being able to change these during a session (not only before connect) would let users tune them from the app's own settings while wearing the headset, which is how we found our values.

I'm looking to find the best setup for a game on AVP that gives the best quality environment with gameplay but there seems to be a mix of possible solutions each with their own drawback. My ideal scenario is a high fidelity room/environment while making use of the PS VR2 Sense controllers to track the user's hands and give them more inputs via the controllers. Eg they hold a weapon tracked to the controllers with the buttons able to use the weapon, shooting and hitting enemies in the room. I want to aim more for highest qualtiy gaming than cartoony so opted for foveated streaming from the Mac as my ideal, but this seems limited to only having some base inputs from the hands and no controller inputs for hand and positional tracking from the controller movement (as they need the data from the Vision Pro camera but the game is technically running on the Mac and streamed to the VP) The only real solution for what I want here is to go via RealityKit as a native Vision Pro app but this reduces the game quality I had in mind as the entire thing is now rendering on the VP instead of the Mac. Am I missing something here or is this a real limitation today? To reitarate I'm looking for: highest fidelity game quality (rendering as much as possible on the Mac) tracking the VR2 Sense controller's positions (to track a weapon) in 3D space

I was wondering whether there is a way to authenticate a CloudXR connection without using a QR code in a local deployment scenario. If the server is running in a headless environment, QR code-based authentication would not be practical. I reviewed the documentation but could not find any information on alternative authentication methods. Is a non-QR authentication workflow similar to the remote case supported?

We are evaluating a consented research study in which a participant freely looks at a painting streamed from a desktop Unity/OpenXR application to Apple Vision Pro. A custom Foveated Streaming provider extension would read FoveatedStreamingProviderContext.latestFocusRegion during an active streaming session and classify the approximate focus direction into a painting-region identifier. No pinch or other action would be required. Is an approved provider permitted to export and retain timestamped painting-region identifiers for research analysis? If so, may it also retain the focus region’s direction, distance, and timestamp, or only the derived region? Is there a supported path for sending the derived data to the paired app or remote endpoint? What entitlement-review, consent, privacy, data-use, and distribution conditions apply? We understand the provider entitlement requires Apple approval and that ordinary visionOS apps do not receive passive gaze data. We would request the entitlement only if this research use is allowed. We are seeking guidance on permitted use before implementing or collecting data.

I'm building a visionOS 26 app that uses SpatialTrackingSession with .accessory tracking and AnchoringComponent.AccessoryAnchoringSource to track a Logitech Muse, following the pattern from the WWDC25 "Explore spatial accessory input on visionOS" session (and matching two independently published implementations I found). What works: The Muse pairs fine over Bluetooth, connects as a GCStylus (productCategory == .spatialStylus), GCStylusDidConnect fires, and button input (pressedDidChangeHandler) works correctly. What doesn't: SpatialTrackingSession.run() always reports .accessory as unavailable, so AnchoringComponent.AccessoryAnchoringSource(device:) never succeeds. Checking Settings > General > Spatial Accessory on the device shows the Muse isn't listed there at all — not even a battery/status entry. Settings > Privacy & Security > Spatial Accessory also never lists our app. What I've tried: Forgetting the Muse in Bluetooth and re-pairing Full power-cycle of both Bluetooth and the Muse itself Confirmed NSAccessoryTrackingUsageDescription is set and the Accessory Tracking + Game Controllers (Spatial Gamepad) capabilities are enabled in Xcode Confirmed via Apple's own docs, the WWDC session, and two developer write-ups that no special commissioning step beyond standard Bluetooth pairing should be needed For comparison, XR Putt (which also uses the Muse) works fine and does show up with a green checkmark under Spatial Accessory permissions on the same headset. Has anyone hit this specific "device never gets commissioned as a spatial accessory" issue, or knows what actually triggers that commissioning beyond generic Bluetooth pairing? Happy to share more logs/details.

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.

I’m using AR Quick Look via (I dont know what this means) for a web-based art catalogue. (I generate usdz in a script on github and display The same USDZ behaves differently: iPhone 6 — iOS 12.5.8: renders correctly as a rectangular painting. iPhone 12 — current iOS: renders as an oval, with no visible thickness. The USDZ renders correctly as a rectangle with thickness in other web/USD viewers. Geometry is explicitly rectangular with two triangular faces, UVs, normals and physical dimensions. Is there a known AR Quick Look / RealityKit compatibility issue with simple textured rectangular USDZ meshes on newer iOS versions? // I have no background in coding but this seems to be a bug on the latest quicklook software?? github here if it helps: https://github.com/mrkritor-ui/KRITOR

Hi Everyone, we've started working on the Xicap tag, a new general purpose active spatial accessory puck for the Vision Pro here at Xikaku. It can be attached to any type of rigid object or will work as a wearable device. We're adding customizable buttons and IO ports for switches etc. to make it versatile for all kinds of tracking applications. I created an intro on our blog with some more info: https://xikaku.com/blog/xicap-vision-pro-spatial-accessory Happy to receive any kind of feedback or comments so we can kepp that in mind while finalizing the device. Klaus

I am implementing a custom generic spatial accessory according to Section 20 of the Accessory Design Guidelines dated 2026-06-08. Apple Vision Pro discovers the accessory, completes BLE pairing and encryption, reads the Apple Spatial Accessory Version and Uniform Type Identifiers characteristics, and recognizes the device in the accessory tracking debug view. However, visionOS writes ASA protocol version 00.00 to the Apple Spatial Accessory Host Version characteristic instead of selecting version 01.01. Here is the log message when I connected my spatial accessory with apple vision pro with os27 beta 3. The error is the ASA part. BLE advertising: ZemScannerASA15; BLE ATT MTU tx=23,rx=23; BLE conn timing connected: interval=30000; us,latency=0,timeout=72; TimeSync anchor report enabled: h=0x011f; BLE connected TimeSync anchor #1 ce=0,int=30000,delay=0 TimeSync anchor #2 ce=3,int=30000,delay=0 TimeSync anchor #3 ce=4,int=30000,delay=0 BLE ATT MTU tx=293,rx=65 BLE security level 2 BLE pairing complete, bonded ASA version read #1 off=0 req=64 hex=02 01 01 01 01 ASA UTI read #2 off=0 req=64 total=49 ASA host wr #3 o=0 l=4 f=00 hex=00 00 01 31 ASA host raw: off=0,write=4,total=4,hex=00 00 01 31 ASA host version: >len=4,ver=0.0,features_len=1,features=0x31 ASA host selected no common protocol HID direct input report sent HID notif #4 report=3 enabled HID IMU stream started HID notif #5 report=2 enabled HID IMU report sent BLE conn params updated: interval=7500 us,latency=4,timeout=100

Building Dasher (eye-gaze text-entry system for people with motor impairments — ALS, cerebral palsy, etc.) for visionOS. See https://github.com/dasher-project/Dasher-Apple The app needs continuous (x, y) gaze coordinates to steer a zooming alphabet interface. Vision Pro has incredible eye tracking hardware built in — this should be the perfect platform — but I can't get gaze coordinates through any API I've tried. What I've tested (all deliver zero events in a windowed app): UIHoverGestureRecognizer — Apple's docs say it "detects when the user is looking at a view" on visionOS. Added it to a UIView inside UIViewRepresentable. Looked at the view for 2+ minutes on real hardware. Console.app shows zero began/changed/ended callbacks. .onContinuousHover (SwiftUI) — zero .active phases delivered, whether attached to the canvas view or the ZStack root. UIPointerInteraction with a delegate — regionFor callback never fires. The system clearly is tracking gaze — I can see beginScrollingWithRegion events in Console.app with the correct window rect, and the visual hover highlight appears on buttons. But the coordinates are routed to scroll handling, not exposed as a usable pointer position. What does work: pinch-and-drag follows the hand position (where the pinch is in 3D space), not gaze. That's fine for general apps but doesn't help users who need eye-only control. What I'm wondering: Has anyone successfully received continuous gaze coordinates in a windowed (non-immersive) visionOS app? If so, which API? Is UIHoverGestureRecognizer supposed to work on UIView inside UIViewRepresentable, or does it require a pure UIKit view hierarchy? Is there an ARKit provider for eye tracking that I'm missing? I see HandTrackingProvider but no EyeTrackingProvider in the capability list. Could the issue be that my SwiftUI overlay (toolbar VStack) is intercepting hover events before they reach the canvas underneath? If so, how do you make a SwiftUI overlay pass-through for hover? Dasher is a well-established accessibility tool that lets people type using only their eyes. Its the fastest text entry method for eyegaze and head controlled systems. On every other platform (iOS with external trackers, Windows with Tobii, etc.) it reads continuous gaze coordinates and zooms toward wherever the user is looking. Vision Pro should be the best hardware for this — the tracking is already there, we just can't read it. If there's no public API for this, I'd love to know so I can scrap my feedback assistant entry!. If there IS a way and I've missed it, I'd be grateful for a pointer. 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 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?