I am trying to create an app where I have multiple users modifying an entity at runtime similar to collaborative digital sculpting using SharePlay on VisionOS. When creating a collaborative experience using other 3D engines I have utilized an external server that devices send and update their state from serving as a global "source of truth". This doesn't seem to be the intended workflow for SharePlay which seemingly only allows for device to device messaging. While this works for a variety of apps it doesn't provide a smooth experience when multiple users are interacting with and manipulating the same 3D entity. Is there an intended way to do this for SharePlay? Would the best practice be to have one user serve as a host and establish a "source of truth" based on their app state? The closest example in documentation I have found is an example for using SharePlay in a drawing app. When a user is drawing they send the information for their realtime stroke through unreliable SharePlay messages and then, when they've finished, they send a reliable message with the final line. This technique makes sense for the given example since there is no scenario where multiple users would be drawing the same line, but it seemingly falls short for my use case since multiple users can sculpt in the same area of a given mesh. What would the intended approach be to achieve this with SharePlay? Is it simply a limitation of this type of networking? Thanks!

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!

I’m developing two complementary developer tools: Reality Prep Pro on macOS and Reality Prep Preview on visionOS. The workflow I’m trying to solve is: Mac: prepare and validate a USDZ Vision Pro: verify that exact USDZ on-device Mac: bring the device evidence back and associate it with the exact asset revision I currently use the USDZ’s SHA-256 as the authoritative identity. If the asset bytes later change, the previous Vision Pro evidence is treated as stale and a re-test is recommended. Existing USDZ→USDZ preparation is package-preserving, so non-texture payloads such as animation/rigging data are not unnecessarily re-authored. I’d be interested in hearing from other RealityKit / Reality Composer Pro developers: Is this similar to how you currently handle asset provenance between desktop preparation and real-device testing? Are there any Apple frameworks or established visionOS practices you would recommend for strengthening this kind of revision-to-device-evidence workflow?

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?

Hello. I trained an ObjectTracker.referenceobject using ML, and am using it in RCP. After adding Anchoring to the entity, I set the Target mode to Object and applied the trained model data ObjectTracker.referenceobject. However, there is no tracking effect after building for VisionPro. Are any permissions required? What should I do?

On visionOS 26.6 and 27 latest beta: PresentationComponent in a volumetric WindowGroup, when looking at the volume from a specific lower/back region create two bugs: buttons inside the presentation have their gaze obstructed by hand presence, no button shows any hover highlight hand movement in that specific area auto dismisses the presentation The focused public repro uses a thin ModelEntity with InputTargetComponent and ordinary SwiftUI buttons. Its README includes two clearer videos: https://github.com/mesqueeb/PresentationAutoCloseInBackOfVolume 1. Gaze obstructed on buttons when hand is at specific location (see "Test Action" has no hover highlight, even though i look at it) 2. Hover state restored on buttons when hand is gone (see "Test Action" has hover highlight) 3. Presentation auto closed when hand comes back The weirdest part: This only happens at a specific location, when walking to the back of the volume, then turning around and interacting with the volume from the lower right back side. Any workaround or fix guidance would be appreciated. Feedback Assistant: FB24569418.

In Xcode it's extremely convenient to be able to sign into AI providers by having an authentication workflow opened in a browser. Reality Composer Pro 3 Beta 5 requires you to manually configure the AI provider (Claude for example). Please provide the Web-based authentication workflow in Reality Composer Pro that is also available in Xcode.

I noticed that there is a Level of Detail component in beta in RealityKit, along with the new GaussianSplatResource component. Apple Maps 3D clearly uses some combination of these things, in addition to some form of streaming and compression most likely, in order to make performance acceptable. It would be nice if Apple could give us some examples of combining file compression + LevelofDetail + GaussianSplatResource in an example project. This is what will be required to make any kind of immersive 3D walkthroughs possible with these frameworks. I just randomly stumbled upon the LevelOfDetail component bc it was mentioned in a Google AI response, but otherwise there seem to be no examples that use it with respect to GaussianSplatResource (and so it’s not clear if it’s meant to be used in this way)

Reality Composer Pro 3 cannot create a new project or open an existing project on my Mac. After I select Create New Project or Open Existing Project, the operation begins but the project editor never appears. The Reality Composer Pro process remains alive and idle, and no standard crash report is generated. Environment: MacBook Pro Mac15,9 Apple M3 Max, 48 GB unified memory macOS 26.6 (25G72) Reality Composer Pro 3 Beta 4, version 3.080.0.1.500.1 Built-in display only Steps to reproduce: Quit Reality Composer Pro. Launch /Applications/RealityComposerPro.app. Select Create New Project. Observe that the editor never appears. Open Existing Project fails in the same way. The problem is reproducible 100% of the time with Reality Composer Pro 3 Beta 2, Beta 3, and Beta 4. I have also reproduced it: With a completely blank new project With an existing project In a clean local macOS user account In Safe Mode With no external displays With local paths and iCloud disabled After verifying adequate free disk space and separately testing free-space conditions After resetting Reality Composer Pro state and preferences The application passes code-signature and Gatekeeper verification. Its temporary loader copy is created successfully, with no ENOSPC, failed-copy, or failed-write error. The failure occurs around libtm-welcome_window.dylib and libtm-plugin_support.dylib prepareToLoad. A small modal NSPanel repeatedly performs AppKit/SwiftUI constraint updates and reports: The window has been marked as needing another Update Constraints in Window pass, but it has already had more Update Constraints in Window passes than there are views in the window. The exception appears to be swallowed instead of crashing the process. A process sample then reports SOME_OTHER_THREAD_SWALLOWED_AT_LEAST_ONE_EXCEPTION while the main thread remains idle in the normal NSApplication event loop. This appears to be a constraint-update loop in the welcome-window loader/progress panel, rather than a problem with a particular project or its assets. Feedback Assistant report: FB24460905 Has anyone reproduced this on macOS 26 with Reality Composer Pro 3? Is there a supported workaround that bypasses the failing loader/progress panel? Is RCP 3 Beta 4 expected to work on macOS 26.6, or does it require macOS 27?Reality Composer Pro 3 cannot create a new project or open an existing project on my Mac. After I select Create New Project or Open Existing Project, the operation begins but the project editor never appears. The Reality Composer Pro process remains alive and idle, and no standard crash report is generated. Environment: MacBook Pro Mac15,9 Apple M3 Max, 48 GB unified memory macOS 26.6 (25G72) Reality Composer Pro 3 Beta 4, version 3.080.0.1.500.1 Built-in display only Steps to reproduce: Quit Reality Composer Pro. Launch /Applications/RealityComposerPro.app. Select Create New Project. Observe that the editor never appears. Open Existing Project fails in the same way. The problem is reproducible 100% of the time with Reality Composer Pro 3 Beta 2, Beta 3, and Beta 4. I have also reproduced it: With a completely blank new project With an existing project In a clean local macOS user account In Safe Mode With no external displays With local paths and iCloud disabled After verifying adequate free disk space and separately testing free-space conditions After resetting Reality Composer Pro state and preferences The application passes code-signature and Gatekeeper verification. Its temporary loader copy is created successfully, with no ENOSPC, failed-copy, or failed-write error. The failure occurs around libtm-welcome_window.dylib and libtm-plugin_support.dylib prepareToLoad. A small modal NSPanel repeatedly performs AppKit/SwiftUI constraint updates and reports: The window has been marked as needing another Update Constraints in Window pass, but it has already had more Update Constraints in Window passes than there are views in the window. The exception appears to be swallowed instead of crashing the process. A process sample then reports SOME_OTHER_THREAD_SWALLOWED_AT_LEAST_ONE_EXCEPTION while the main thread remains idle in the normal NSApplication event loop. This appears to be a constraint-update loop in the welcome-window loader/progress panel, rather than a problem with a particular project or its assets. Feedback Assistant report: FB24460905 Has anyone reproduced this on macOS 26 with Reality Composer Pro 3? Is there a supported workaround that bypasses the failing loader/progress panel? Is RCP 3 Beta 4 expected to work on macOS 26.6, or does it require macOS 27?

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.

While loading PLY and USDZ is nice, it would be great to support more compressed formats like SPZ and SOG: https://www.nianticspatial.com/en/blog/spz4 Is this something that might be in the works? Or if Apple releases their own compression, that could work also. PLY tends to be quite large for models of any size.

I have a RealityKit scene with one container entity and two children: an entity carrying a GaussianSplatComponent, and a plain Entity with a ModelComponent (an unlit white cube). A single OpacityComponent goes on the container, so one value covers both children in the same frame. container.components.set(OpacityComponent(opacity: value)) On visionOS 27 this does exactly what I expect: both children fade together, continuously, across the whole range. On iOS 27 and Mac Catalyst 27 the cube fades continuously but the splat does not. It renders at full opacity for every value above 0 and disappears at exactly 0. At 0.01 the cube beside it is already almost invisible while the splat is still drawing at full strength, so entity opacity behaves as a visibility switch on a splat rather than as a blend factor. Things I have already ruled out: Not a propagation issue. Moving the OpacityComponent off the container and onto the splat's own entity (and the cube's own entity, to keep the A/B) changes nothing. Not the container failing to receive the value. The cube under the same component, in the same frame, fades correctly. Not the splat data. Per-splat alpha through GaussianSplatResource's opacity buffer is honoured, and projectionMode, sortingMode, scaleActivation and opacityActivation all take effect. Not a difference in scene construction per platform. The same file builds the container on all three platforms in my sample. Confirmed on: iOS 27.0 (24A5418b), iPhone 16 Pro — reproduces macOS 27.0 (26A5416b), Mac Catalyst — reproduces visionOS 27.0 (24M5326g), Apple Vision Pro — correct Filed as FB24431214 with a sample project that builds for all three from one target. Would be great to see this fixed!

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.

If the immersive environment is fully open, then an immersive space is closed right after attempting to open it. The issue specifically impacts a mixed immersive space which replaces the immersive environment while the immersive environment is at 100%. This issue does not occur if immersive environment is any less than 100%, or if the immersionStyle is .full, or if immersiveEnvirionmentBehavior is .coexist. This can be reproduced in the template for an immersive visionOS app by removing the line .immersionStyle(selection: .constant(.full), in: .full) Then run the app and open the immersive space, and the space then closes after attempting to open it. I’m using visionOS 27.0 beta 5 and Xcode 27.0 beta 5. I've submitted feedback as FB24353599 Video of the behavior: https://youtu.be/wafDXRZVyog

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

Can I use Vision OS, on Mac with intel(2019) ? If yes with what version of Xcode?

I'm building a Wacom tablet-driven cloth editing rig in visionOS: a persistent grab sphere (one Entity with ClothGrabComponent, volume mode) parented to the simulation root, toggled with isGrabbing on each pen-down. A single grab behaves correctly — the cloth follows the sphere, nothing else moves. On the second grab at a different position (same cloth, no rebuild), the component keeps dragging the particles from the FIRST grab to the new sphere position — its internal grab coordinates are not updated by the new activation. The vertex that was just bound is pushed away from the sphere at the same time. Instrumented demo is (0.5 × 0.5 m grid, 289 vertices, four corners pinned, gravity = 0, sphere radius 0.06, falloff = .disabled), grab A at vertex #294 (−0.118, +0.118), release, then grab B at vertex #105 (+0.118, −0.118) — 0.335 m apart: t = 345.9 GRAB_B starts: previous #294 disp = 0.000 dist-to-ball = 0.335 current #105 disp = 0.000 dist-to-ball = 0.000 t = 346.4 (+0.5 s): previous #294 disp = 0.335 dist-to-ball = 0.000 ← dragged to the NEW ball current #105 disp = 0.191 dist-to-ball = 0.191 ← pushed AWAY from the ball t = 347.0 … 349.6 previous #294 pinned at ball (dist 0.000), #105 held away at 0.16–0.19 t = 351.9 after release: #294 back to rest (0.012), cloth flat again The 0.335 m displacement of #294 happens within half a second and equals exactly the distance from #294's rest position to the new sphere — the previous grab's particle set is being pulled toward the new sphere location, as if the component re-applied the old grab selection with the new transform. this can repeat with identical numbers. The docs for isGrabbing only say "Indicates whether particles are currently being grabbed" — they don't describe what happens on a false→true transition after the entity has moved, which is the case the official sample never demonstrates. The setup is the one shown in the official sample — a persistent entity carrying the grab component, isGrabbing toggled per interaction: // makeCloth — once let dragBall = makeBall(radius: 0.015, parent: simRoot) var grab = ClothGrabComponent(mode: .volume(shape: .sphere(ClothSphereShape(radius: 0.06)))) grab.falloff = .disabled dragBall.components.set(grab) // grab: move ball to new vertex, activate dragBall.position = body.convert(position: vertexPos, to: simRoot) var g = dragBall.components[ClothGrabComponent.self]! g.isGrabbing = true dragBall.components.set(g) // release: deactivate only var g = dragBall.components[ClothGrabComponent.self]! g.isGrabbing = false dragBall.components.set(g) some tries： Remove and re-add ClothGrabComponent on each grab — the simulator crashes within 1–2 frames with Assertion failed Rebuild the whole ClothBodyComponent between grabs Environment: Xcode 27 beta (build 24M5316i), xrOS 27.0 SDK, simulator runtime com.apple.CoreSimulator.SimRuntime.xrOS-27-0 (avp1). All Cloth* APIs are Beta on visionOS 27