After updating to visionOS 27.0, WorldTrackingProvider.allAnchors returns WorldAnchor.originFromAnchorTransform values that do not match what anchorUpdates delivers for the same anchor, read at the same moment, both isTracked == true, with no .updated event in between. The difference is a rigid frame change, not drift: Same vertical offset on every anchor: -1.173 m. Identical across two apps and two days with the head at 1.13 m and 1.22 m, so a constant, not head height. Horizontal deltas vary per anchor, but inter-anchor distances are preserved, so it is a yaw plus translation. Stable over time, same across launches. anchorUpdates matches the ImmersiveSpace frame RealityKit draws in. allAnchors does not. On visionOS 26 both agreed. Same anchor, same instant: allAnchors (0.1486, -0.7143, 0.2231) anchorUpdates (0.1316, 0.4590, -1.0955) device pose (0.0073, 1.2195, -0.0038) Four other anchors, delta = allAnchors - anchorUpdates: ( 2.6933, -1.1733, -0.2514) (-0.0810, -1.1733, 1.1339) ( 0.1878, -1.1733, 0.9891) ( 2.6289, -1.1733, -0.1809) In our app this showed up as a placed model vanishing after a scene switch: we re-pinned the model root from allAnchors, and it landed below the floor behind the user. A standalone sample (one provider, one anchor, a green sphere from anchorUpdates, a red sphere from allAnchors) shows two spheres on visionOS 27.0, the red one below the floor: added F21942C4-… at (-0.031, 0.712, -0.976) update added F21942C4-… tracked=true at (-0.031, 0.712, -0.976) MISMATCH delta (-0.211, -1.173, 1.444) m allAnchors (-0.243, -0.461, 0.468) anchorUpdates (-0.031, 0.712, -0.976) tracked=true device (0.000, 1.129, -0.001) Questions: Is allAnchors now intentionally expressed in a different frame on visionOS 27, for example related to the new ARKitCoordinateSpaceProviding / coordinateSpace(correction:) API? The documentation for allAnchors does not mention it. If so, which frame is it, and how should it be converted to the ImmersiveSpace frame? Workaround we use: read transforms only from anchorUpdates into a per-id cache and never position from allAnchors. Filed as FB24799304. Minimal repro project attached to the feedback.

We are working on a very space constrained custom spatial accessory. Since the form factor of the device is small, we need to add small LEDs producing small blob diameters with accordingly small distance between them. To better estimate the amount, size, and distance of the LEDs it would help to know which image sensors and field of view the six world‑facing tracking cameras have.

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

Hi, I’m looking to develop an app that uses the iPhone’s LiDAR scanner and am trying to decide which model to buy. Is there any relevant technical documentation available on its capabilities, such as accuracy, resolution and range? I’d also like to understand whether there have been any improvements between generations, particularly with the iPhone 18 Pro. Any documentation or pointers in the right direction would be appreciated. Thanks!

We are developing a generic spatial accessory for Apple Vision Pro using the “Working with generic spatial accessories” sample and a trained .referenceaccessory file. Environment: visionOS: [version/build] Xcode: [version/build] Hardware: Apple Vision Pro + nRF52840-based BLE accessory IMU: 6-axis IMU, 400 Hz HID reports LED constellation: 8 x 850 nm IR LEDs, driven through MOSFETs The BLE/HID and timing path appears to be working: The accessory connects successfully over BLE. ASA/HID enumeration succeeds. The firmware receives continuous LED Output Reports from visionOS. The Accessory Tracking Clock reaches READY. PWM scheduling reports no late events and no queue overflow. In the Accessory Tracking Debug View, multiple independent IR LED blobs are visible and stable at approximately 0.7 m. At least 4 LEDs are visible from normal viewing angles. The app resolves the .referenceaccessory and starts AccessoryTrackingProvider. However, ARKit never produces an AccessoryAnchor. We also have no diagnostic signal indicating whether the failure occurs at: LED candidate-point detection, constellation matching against the .referenceaccessory, or IMU/optical fusion. Questions: Is there a supported diagnostic API, log category, or Debug View indicator that distinguishes candidate-point rejection from constellation-match or fusion rejection? Are there known acquisition prerequisites in the current visionOS beta beyond the published Accessory Design Guidelines? Can Apple recommend a minimal validation procedure using the generic spatial accessory sample to confirm that the LED constellation is accepted by the tracking system? Is this expected to work in a volumetric window, or are there additional lifecycle/session requirements that can prevent initial acquisition? I can provide sanitized HID LED-report logs, timing data, Debug View captures, and a minimal reproducible project if useful.

Summary A SpotLightComponent with SpotLightComponent.SurroundingsLight() (and a ProjectiveTexture) lights the flat part of my ceiling and the walls, but never the two sloped ceiling surfaces of a converted attic room, at any angle, intensity, attenuation radius or falloff. The lit area stops in a hard straight line exactly where the flat ceiling meets each slope, even though the beam clearly extends past that line. The sloped surfaces are fully present in SceneReconstructionProvider's mesh, and their faces point into the room. So this doesn't look like a scene understanding coverage problem. It looks as if physical space lighting only considers surfaces classified as horizontal ceiling, wall or floor, and skips slanted ones. Steps to reproduce Open a mixed immersive space in a room with a sloped ceiling (a converted attic, or any vaulted ceiling). Add an entity with SpotLightComponent(color: .white, intensity: 40_000, innerAngleInDegrees: 44.5, outerAngleInDegrees: 45, attenuationRadius: 10), SpotLightComponent.SurroundingsLight(), and a SpotLightComponent.ProjectiveTexture carrying a labelled grid texture so the beam's extent is visible. Place it near the floor under the wearer and aim it straight up. Run SceneReconstructionProvider alongside and draw each MeshAnchor as a wireframe (or as a solid material with faceCulling = .back) to confirm the mesh covers the slopes and faces inward. Expected The projected pattern conforms to every surface in the scene understanding mesh inside the cone, including the sloped ceiling, as it does for the flat ceiling and walls. Actual The pattern appears only on the flat ceiling strip and on the walls. Both slopes stay completely dark, with a hard straight cut at the crease. Tilting the light to aim directly at a slope, raising intensity to 200,000, and changing attenuation radius and falloff make no difference. The wireframe shows continuous mesh across the crease and onto the slopes; the back-face-culled solid view shows the slope faces pointing into the room. Screenshots attached: (1) the projected grid stopping at the crease, (2) the reconstruction wireframe covering the slopes, (3) the solid front-faces-only mesh showing the slopes are front-facing. (4) an additional image of the projected grid with both ceiling and walls in view Code let spot = Entity() spot.components.set(SpotLightComponent.SurroundingsLight()) var light = SpotLightComponent(color: .white, intensity: 40_000, innerAngleInDegrees: 44.5, outerAngleInDegrees: 45, attenuationRadius: 10) light.attenuationFalloffExponent = 0.5 spot.components.set(light) spot.components.set(SpotLightComponent.ProjectiveTexture(texture: gridTexture)) spot.look(at: from + SIMD3(0, 1, 0), from: from, upVector: SIMD3(0, 0, -1), relativeTo: nil) root.addChild(spot) Questions Is physical space lighting limited to horizontally and vertically classified surfaces by design? If so, could this be documented on SurroundingsLight, and is there a way to include slanted surfaces? If not by design, is there anything an app can do to have the light use the full reconstruction mesh?

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!

Hi, I'm building an iOS LiDAR scanning app using ARWorldTrackingConfiguration with sceneReconstruction = .mesh. During scanning I save the RGB image, ARFrame.camera.transform, intrinsics and per-frame scene depth. At the end of the scan I also have the final ARMeshAnchor mesh. When I place the saved depth observations into the ARSession world using their original ARCamera.transform, they broadly form the same scene, but over a longer walk I can see several-centimetre discrepancies between observations of the same surfaces. My question is very specific: After ARKit has built its world map / reconstructed the environment, is there any public API that provides a globally refined or corrected historical pose for previously captured ARFrames, rather than the original ARCamera.transform recorded at each frame? In other words, is there an API or ARKit data structure from which I can obtain something equivalent to: frame timestamp → refined world-space camera transform after the session has accumulated more information? I am aware of ARWorldMap and worldMappingStatus, but I'm unclear whether the world map contains information that can be used to recover or refine the historical camera trajectory, or whether ARCamera.transform is the only historical pose available to an app. I'm not looking for advice on implementing ICP or my own SLAM/registration. I just want to know whether ARKit already exposes a refined trajectory or the underlying information needed to obtain one. Thanks.

We are developing a LiDAR-based spatial capture application using ARKit and RealityKit. We are investigating whether PhotogrammetrySession can be used as part of a capture pipeline where we collect: RGB frames LiDAR depth camera intrinsics camera transforms IMU/device motion data and then reconstruct a textured 3D model. The documentation states that PhotogrammetrySample can include depthDataMap, depthConfidenceMap, gravity, and camera metadata. Could someone clarify how PhotogrammetrySession uses the depth information when supplied? Specifically: Is LiDAR depth used during reconstruction to improve geometry (for example as a constraint during reconstruction), or is it primarily used for scale/orientation metadata? When camera transforms and intrinsics are available from ARKit, does PhotogrammetrySession consume this information, or does it independently estimate camera poses from the image sequence? Is the recommended Apple workflow for RGB + LiDAR capture: ARKit capture → PhotogrammetrySample → PhotogrammetrySession or is ObjectCaptureSession the intended capture pipeline for photogrammetry workflows? We are trying to understand the intended relationship between ARKit, ObjectCaptureSession, and PhotogrammetrySession before choosing an architecture. Thanks.

I have a few questions about the recommended approach: Should a large area like this be scanned in a single RoomCaptureSession, or is it recommended to split it into multiple sessions? If multiple sessions are preferred, should the decision be based on the device's available RAM/memory or the size of the scanned area (square footage)? Is there a recommended maximum square footage, number of rooms, or session duration for a single RoomCaptureSession? Are there any documented limitations or best practices for handling large-area scans with RoomPlan? I'm looking for the recommended approach from the RoomPlan/ARKit developer for managing large scans efficiently.

I have read in the apple documentation and on forums that in order to access the camera and capture images on VisionPro, both an Entitlement and an Enterprise.license are required. I already have the Entitlement, but I don’t yet have the Enterprise.license. I would like to ask: is the Enterprise.license strictly required to gain camera access for capturing images? How can I obtain this file, and does it require an Enterprise account? Currently, my developer account is a regular Developer 99$, not an Enterprise account.

Hello, I'm a VTuber, or a content creator who uses a virtual avatar instead of my real life face for presentation. I've been trying to use the iOS implementation of ARKit to get face tracking working, but noticed a major issue, especially for my purposes. ARKit appears to move both eyebrows the same, regardless of whether or not I am physically moving my eyebrows the same. Every ARKit based application I've used simply mirrors eyebrow movement. Is there a fix to this, or is this just a bug currently in the software?

Hello Apple Developer Team, We are currently developing an enterprise medical navigation application for Apple Vision Pro and would like to request clarification regarding the currently available visionOS Enterprise APIs related to camera access. Our application scenario involves real-time medical/surgical navigation and instrument tracking in a professional enterprise environment. We would like to better understand the following: How many cameras on Apple Vision Pro are currently accessible through the Enterprise APIs? Which specific cameras are accessible? For example: Main RGB cameras Passthrough cameras Tracking cameras Front-facing cameras Depth sensors LiDAR or structured-light related sensors Are simultaneous multi-camera streams supported? Does the Enterprise API provide: Real-time image frames Camera intrinsic/extrinsic parameters Stereo camera data Depth information Low-latency tracking-related data Are there any restrictions regarding the use of Vision Pro cameras for: Medical navigation Surgical guidance Instrument tracking Enterprise healthcare software Is Apple Vision Pro currently permitted or recommended for medical enterprise spatial-navigation workflows under the Enterprise APIs? We would greatly appreciate any official clarification regarding the current capabilities and limitations of camera access on Apple Vision Pro for enterprise medical applications.

Bug: When SpatialTrackingSession and ARKitSession + WorldTrackingProvider are running concurrently, any WorldAnchor added via WorldTrackingProvider.addAnchor() triggers .added followed immediately by .removed—without any user call to removeAnchor(). The anchor never persists in allAnchors. import SwiftUI import RealityKit import ARKit struct ImmersiveView: View { @State private var worldTracking: WorldTrackingProvider? @State private var arSession: ARKitSession? @State private var processWorldTrackingUpdatesTask: Task<Void, Never>? var body: some View { RealityView { content in let configuration = SpatialTrackingSession.Configuration(tracking: [.world]) if let unavailableCapabilities = await SpatialTrackingSession().run(configuration) { if unavailableCapabilities.anchor.contains(.world) { fatalError("World tracking is not available on this device.") } } let worldTracking = WorldTrackingProvider() let arSession = ARKitSession() self.arSession = arSession try! await arSession.run([worldTracking]) self.worldTracking = worldTracking processWorldTrackingUpdatesTask = Task { @MainActor [weak worldTracking] in guard let worldTracking else { return } for await update in worldTracking.anchorUpdates { let worldAnchor = update.anchor switch update.event { case .added: print("Anchor added: \(worldAnchor.id)") case .updated: print("Anchor updated: \(worldAnchor.id)") case .removed: fatalError("Anchor removed unexpectedly — this should not happen in this demo scenario.") } } } } .task { try? await Task.sleep(for: .seconds(3)) guard let worldTracking else { return } do { try await worldTracking.addAnchor(.init(originFromAnchorTransform: Transform.identity.matrix)) } catch { print("Error adding anchor: \(error)") } } } } Expected: Anchors persist until explicitly removed or out of range. Actual: SpatialTrackingSession interferes with WorldTrackingProvider's anchor lifecycle, causing immediate removal. This was originally reported in 2025 (https://developer.apple.com/forums/thread/773351) , but remains unfixed in visionOS 27.0 beta. I've re-filed as FB23420195.

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?

My cousin implanted an itch I'd like to scratch. She does some academic psycho-neurological research that I don't fully understand. But in talking it sounds like mixed reality in the AVP might facilitate a type of research that she's pursuing. I just don't know if such a thing is currently possible with the AVP given how it treats physically moving frames of reference. The idea is to have subjects in a motion vehicle simulator rig, able to operate it and see the interior of the vehicle/gauges/etc. But at times and in specific ways, obscure the views out of the "windows" of the vehicle. The obvious problem here is that the AVP doesn't like being in a dynamically moving frame of reference. This seems to be beyond what "travel mode" is intended for. They need to bump and turn the subjects to get the responses they're studying, so not a smooth ride like on a plane or train. The interior of the simulator rig is a "known object" and can be modeled. I just watched the new video about training/tracking a hand-held object via Create ML. Could a similar approach from a hand-held object be applied to the user's surroundings - the mocked up vehicle interior and its window frames? We'd then apply an obscuring blur or even just an opaque polygon to that "window" while the simulator rig (and thus the user) is in motion? The alignment of the blur/polygon doesn't need to have perfect tracking and registration. Update rate does not need to be low millisecond, but full second updates might make motion sickness worse. Also, am I correct in inferring that object tracking should be free from major drift over the course of tens of minutes? A stretch: would it be possible to counteract the illumination from room light sources so that the movement of light/dark is reduced on the interior of the "vehicle" while it is moving? I also noticed in the new "Explore enhancements to visionOS object tracking" video that some of the effect of overlaying MR elements onto something that is visually passed through is being demonstrated on an iPhone. Could a proof of concept of this app(?) be "mocked up" using an iPhone as a basis to justify the expense of buying the AVP? Hold the phone while the rig is moving, track the interior and blur/"open" the windows as seen on the phone screen?

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

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.

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.