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.

Hi, in RealityKit, AudioPlaybackController exposes duration, gain, speed, play/pause/stop, and a completion handler, but I can't find a way to read the current playhead position while a resource is playing. I need this to trigger animations and other timed events in sync with the audio. Is there a supported way to read the current playback position on AudioPlaybackController? If not, is this planned any time soon? Also, is there a sample-accurate way to start/keep audio playback in sync across multiple entities in RealityKit? Appreciate any guidance, thanks.

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!

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?

As a 3D artist specializing in spatial installations, I faced the constant risk of designs looking balanced on screen but failing in physical proportions on the production floor. Starting with no traditional coding background, I embraced AI-assisted development and the CORE learning framework to master Swift, ARKit, and RealityKit. Real ini was built out of real practitioner necessity: turning the iPhone and iPad into on-site spatial validation studios that bridge digital art into physical reality. Download my app for free : https://apps.apple.com/id/app/real-ini/id6805716872

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?

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?

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.

Hi all! I am struggling to make any app because reality composer pro freezes when I click on create new project, as well as it does not appear in Xcode at all. I have tried deleting and redownloading all versions of both Reality Composer Pro & Xcode, as well as restarting my computer. Kindly advise what else I can try. Thank you!

FB24536235 On Mac Catalyst under macOS 27, a plain CADisplayLink asking for CAFrameRateRange(minimum: 60, maximum: 60, preferred: 60) gets serviced at 30 Hz for as long as a RealityView is on screen in the same window. The link does nothing per tick but count, so there's nothing of mine to blame it on. RealityKit's own statistics overlay reads 60.41 fps in the same frame. Click a segmented control that removes the RealityView and the same link goes straight back to 60. Nothing else changes. That's the whole reproducer, and I've attached it to the radar. It only happens while the display panel is in ProMotion mode. Set the built-in to a fixed 60 Hz and it's correct again. With an external 60 Hz display attached the roles swap: the built-in is fine and the external drops to somewhere between 18 and 30, and setting the built-in to 60 Hz fixes that one too without touching the external's own settings. A raw MTKView presenting continuously at 60, at 120, and on a 120 Hz link presenting every second callback are all fine, so it isn't continuous presentation and it isn't the requested rate. It's RealityKit specifically. Worth knowing if you're testing: RealityView on Catalyst is an ARView underneath, so both paths give you the same answer. This is VERY rough for anything that puts RealityKit next to a UI. In an editor that's the sidebar, the inspector, gizmos, drag handles, every display-link-driven or UIKit animation in the window running at half rate around a viewport that stays smooth. Likely Related to FB24091347, which is the same defect seen as SwiftUI scroll judder. If you can reproduce either, please file a duplicate. Attached two screenshots; first with promotion enabled, second with promotion off. PLEASE fix this, it drives me crazy and there seems to be no workaround. On release day of macOS 27 our app will likely be blamed for it by users and my hands are tied. Thank you!

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!

[PhotogrammetrySample]) with objectMask set and traps on my ios26.5.2, see the attached screenshot on feedback FB24379913 , it gets to the function and hangs . Even the folder reconstruction with lazy sequence as recommended from your video sample also doesn;t complete as it can't find alignment and displays the CoreOC.PhotogrammetrySession.Error error 6 means alignment failed. What can be done or do you guys expose any functions that can be used to check or trace or handle these internally The ObjectMasks are actually segmentation masks from an segmentation algorithm I will appreciate a timely response and willing to provide more clarity and informations, thank you so much for your understanding

Xcode hangs when I call PhotogrammetrySession(input: [PhotogrammetrySample]) with objectMask set and traps on some devices, see the attached screenshot, it gets to the function and hangs. Even the folder reconstruction also doesn't complete as it can't find alignment and displays the CoreOC.PhotogrammetrySession.Error 6 and I understand to mean alignment failed. In this case it failed while object masking was ON, so RealityKit could not find enough consistent feature tracks inside the masked pixels across the image set. What can be done or do you guys expose any functions that can be used to aid, or handle these internally, can't find any internally. The ObjectMasks are actually segmentation masks from an ML algorithm . To replicate try calling PhotogrammetrySession(input: [PhotogrammetrySample]) with contentsOf as captured on your documentation, even with like 30 image set or is there something I'm missing. I will appreciate a timely response and willing to provide more clarity and informations, thank you so much for your understanding

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

If a ViewAttachmentComponent moves into frame, it is low resolution until something changes the view while it is in frame. Video demonstrating the behavior: https://youtu.be/KXEFFiAnv1s I am on visionOS 27 beta 4. This did not occur when I was on visionOS 26.5. Also using Xcode 27.0 beta 4 and macOS 27.0 beta 4. To reproduce, have a ViewAttachmentComponent in an immersive space, look away, then look back, and it'll be low resolution. Anything which would change the view while it's in frame will then cause it to update in full resolution. Screenshot of low-resolution view after it moves back into frame from being out of frame: Screenshot after updating the view, making it high-resolution again: I've submitted feedback as FB24116473.

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

Title: GaussianSplatComponent — stale visibility set after close-range camera approach (iOS 27 beta 4, still unfixed) Filed this as a radar during beta 3; still reproduces unchanged on beta 4, so posting here in case anyone from the RealityKit team can confirm it's tracked before this ships. Radar: FB23749559 (filed against beta 3, re-verified on beta 4) Summary On iOS, GaussianSplatComponent keeps a stale visibility set after the camera moves close to and then away from the splat. Moving the camera in close causes a large portion of splats to be culled — expected. But pulling the camera back out does not repopulate them. The visible set stays stale for as long as the current camera transform is held. The missing splats only return once the camera transform changes again — any pan/orbit/zoom delta triggers a recompute and the full splat snaps back. Net effect: after any close inspection, the splat renders permanently partially-culled until the user happens to nudge the camera. The recovery-on-movement / no-recovery-when-stationary signature suggests the iOS render path recomputes splat residency on camera-transform change events rather than every frame. This also reproduces in AR mode, with a completely different camera driver. Since the only thing the two paths share is the splat residency code, that's where the stale set has to be coming from — which also means there's no app-side fix available to me. The camera transform in AR is driven by ARKit, not by my code, so I can't force the perturbation that would otherwise work around it. visionOS 27, running the same component, is unaffected — the visible set is re-evaluated per frame and the splat stays complete. Steps to reproduce Attach a GaussianSplatComponent (~400k splats) to an entity in a bounded RealityView with orbit controls. Move the camera close until a visible portion of the splats is culled. Move the camera back out so the full splat is within the frustum. Hold the camera still. Expected: full splat visible once pulled back. Actual: previously-culled splats stay missing while the camera is stationary; they reappear only on the next camera transform delta. Configuration iOS 27 beta 4 (originally filed against beta 3) iPhone 16 Pro ~400k splats Bounded RealityView + orbit controls; also reproduces in AR Screenshots attached: full splat, stale-culled state after pull-back, and the close-range view that triggers it. This is still present in beta 4 and in the public beta. I'd like to know whether it's tracked, or whether I should plan around splats being unreliable on iOS 27. Thanks!

BloomComponent (RealityKit 27) lags behind the geometry that produces it while the camera moves. The halo trails the emissive geometry by roughly one to three frames (eyeballed) and snaps back once the camera stops. Video attached — it's obvious at normal playback speed. visionOS renders the identical scene correctly. Only iOS and macOS / Mac Catalyst lag, which points at the non-visionOS compositing path rather than the effect itself. Filed as FB23960052. This should be fixed before 27 ships — bloom is unusable for anything with a moving camera in its current state on those platforms. Ruled out: Scope. Identical with BloomComponent(scope: .hierarchical) and .unbounded. .unbounded computes no per-entity screen-space bounds, so stale bounds are not the cause. Input handling. The camera is RealityKit's own .realityViewCameraControls(.orbit) — no gesture code of mine involved. Per-frame component writes. BloomOptionsComponent is set once and untouched during the drag. Geometry and camera transform. Both track perfectly; only the glow lags. Reproducer is ~130 lines, no assets — five emissive spheres inside a large inward-facing dark sphere: var material = PhysicallyBasedMaterial() material.baseColor = .init(tint: .black) material.emissiveColor = .init(color: .cyan) material.emissiveIntensity = 4 // ... root.components.set(BloomComponent(scope: .unbounded)) var options = BloomOptionsComponent() options.strength = 1 options.threshold = 1 options.blurRadius = 1 root.components.set(options) shown in: RealityView { content in content.camera = .virtual content.add(root) } .realityViewCameraControls(.orbit) Xcode 27.0 beta 4, iOS 27.0 SDK, Apple Silicon. Affected: iOS 27, macOS 27 / Mac Catalyst 27. Not affected: visionOS 27 (immersive space). Full project and screen recording attached to my radar.

Hi guys! I wanted to study this new ManipulationComponent(), but I keep getting a warning that I don’t understand, even in a very simple scenario. i don't have any collisions just binding the Manipulation the warning message is : ** Entity returned from EntityWrapper.makeEntity(context:) was already parented to another entity. This is not supported and may lead to unexpected behavior. SwiftUI adds entities to internally-managed entity hierarchies.** RealityView { content, attachments in if let loadedModel = try? await Entity(named: "cloud_glb", in: realityKitContentBundle) { content.add(loadedModel) loadedModel.components.set(ManipulationComponent()) } Thanks !