I’m testing RealityKit cloth for garment-like cloth over an authored human-shaped triangle-mesh collider. The issue also occurs with a static collider, so it does not appear to depend on character animation.. Contact is stable and runs interactively, but I cannot achieve close surface contact without sacrificing robustness. The cloth mid-surface remains visibly several millimetres from the authored collider, especially around curved or narrow areas such as the head, arms, and hands. Transparent rendering of visualMesh confirms this is not just render thickness. Reducing ClothMeshShape.bias reduces the gap, but eventually causes interpenetration around difficult geometry. Increasing it prevents penetration but makes the cloth visibly float. I’ve also checked scale, winding, normals, reasonably even triangles, timestep, and solver iterations. I want to avoid inflating the collider or adding anatomical proxy shapes. Is bias the only physical-clearance control, or does RealityKit apply an additional contact radius derived from simulation-mesh resolution? Is local conforming refinement the recommended way to achieve roughly 1–2 mm clearance while retaining robust real-time contact? Are there any specific topology requirements beyond evenly sized triangles? I can provide a minimal reproduction and screenshots if helpful although not sure I can share screenshots here?

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)

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!

Hello, As far as I understand, RealityKit now supports 3D Gaussian Splatting through GaussianSplatComponent. I would like to ask whether there is currently a way to use 3D Gaussian Splatting data directly in Reality Composer Pro, for example by importing a .ply file containing Gaussian splats. More specifically: Can Reality Composer Pro import a 3D Gaussian Splatting .ply file? Is there a way to create or assign a GaussianSplatComponent to an entity directly within Reality Composer Pro? If this is not currently supported, is there any recommended workflow for creating a .usdz containing Gaussian Splatting data that can be opened in the Preview app on iPhone/iPad and displayed as an AR object? I tried opening the sample plant.usdz on an iPhone using the Preview app. However, the AR preview appears to be empty, so it seems that the Preview app may not currently support rendering the Gaussian Splatting content contained in that USDZ. My desired workflow would be: Gaussian Splatting .ply → Reality Composer Pro / USDZ → iPhone Preview → AR Is this workflow currently possible? If not, is there an official or recommended way to package a GaussianSplatComponent and its associated Gaussian splat data into a USD/USDZ file for AR preview on iOS? If the above functionality is not currently supported, does the development team have any plans to add or improve support for these features in future versions of Reality Composer Pro or the Preview app? Any clarification regarding the current capabilities, limitations, or future plans would be greatly appreciated. Thank you!

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?

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?

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.

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

I’m seeing a device-only lighting discontinuity on PBR entities that intersect a RealityKit portal plane in visionOS 27. A sharp brightness boundary appears exactly where the portal plane cuts through the entity. The portion outside the portal receives a different physical environment-probe contribution from the portion inside. The behavior is reproducible with two independent cases: A completely static blue sphere positioned across the portal plane. An orange sphere moved through the portal using ManipulationComponent and the standard visionOS pinch gesture. Both spheres use: var material = PhysicallyBasedMaterial() material.baseColor = .init(tint: .orange) material.metallic = 0 material.roughness = 1 Each sphere has the crossing and lighting components attached directly: sphere.components.set(PortalCrossingComponent()) sphere.components.set( ImageBasedLightReceiverComponent( imageBasedLight: portalImageBasedLight ) ) var lightingConfiguration = EnvironmentLightingConfigurationComponent() lightingConfiguration.environmentLightingWeight = 0 sphere.components.set(lightingConfiguration) The portal is created using the visionOS 27 factory API: let portal = PortalComponent.makePortal( surfaceStyle: .init(width: 1.2, height: 0.8), boundaryStyle: .infinitePlane(), boundaryMode: .clippingAndCrossing ) if var component = portal.portalEntity.components[PortalComponent.self] { component.lightingBlendDistance = 0.2 portal.portalEntity.components.set(component) } For the moving sphere, environmentLightingWeight stays at 0 for the entire interval in which any part of the sphere intersects the portal. The realtime environment-probe contribution only begins fading from 0 to 1 after the complete sphere has cleared the plane. However, a spatially sharp edge remains: In a bright physical environment, the outside portion is brighter. In a dark physical environment, the outside portion is darker. With UnlitMaterial, the edge disappears completely. With PBR—even metallic 0 and roughness 1—the edge returns. The static sphere reproduces the issue, so it does not appear to be caused by gesture or lighting-update timing. Changing lightingBlendDistance does not soften this remaining edge. The issue is visible on Apple Vision Pro but not in visionOS Simulator. I watched the portal-lighting section of WWDC24 session 10103 and implemented the recommended EnvironmentLightingConfigurationComponent solution. I have also reviewed the documentation for PortalComponent, PortalCrossingComponent, PortalComponent.makePortal, ImageBasedLightReceiverComponent, and environmentLightingWeight. Is there another component or entity-hierarchy requirement needed to fully suppress the physical environment probe on the host-side fragments of a crossing PBR entity? Or is this a RealityKit rendering issue on physical hardware? Environment: Apple Vision Pro (M5) visionOS 27.0 (24M5326g) Xcode 27.0 (27A5228h) visionOS SDK 27.0 (24M5326e) Here is a minimal standalone Xcode reproduction containing both the static and pinch-draggable spheres: https://drive.google.com/file/d/13qqOlDJVCCtlFcMaHCBpDkVJgRzmNjBK/view?usp=sharing

Hello, I have multiple models that use different shaders to create hover effects. How can we make one of these models hover while the other models also switch to hover state?