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?

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!

Why do I play an AIVU 180 degree video, which has always been able to play smoothly, and then suddenly played too laggy recently? The video is embedded locally, without network factors, and the video parameters and program code have not changed at all. I also tested playing videos around 400m in size, and the CPU displayed 400-500%, but it was very smooth. When playing a video of 1G or so, the clip is 20-30%, but it is too laggy. Except for the different video duration, other parameters are the same. May I ask what caused the lag.

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.

Hello, and thank you for taking questions this week. We develop DeepWalk, a production App Store application that captures LiDAR depth, RGB, and ARKit camera poses while field technicians walk continuous outdoor routes (sidewalk and infrastructure assessment). Recorded ARCamera.transform values are used downstream for 3D reconstruction, so world-tracking accuracy directly determines our output quality. Problem: Beginning in early April 2026 and coinciding with the iOS 26.4 rollout across our device fleet, we observe directional, accumulating pose drift in recorded trajectories during normal walking motion. The behavior matches the regression reported in forum thread 827240 (world-tracking drift on LiDAR devices on iOS 26.4+, absent on non-LiDAR devices running identical code). Link to existing post here: https://developer.apple.com/forums/thread/827240 Our configuration is minimal: a default ARWorldTrackingConfiguration with frameSemantics = [.sceneDepth, .smoothedSceneDepth] and no other options set, running on a bare ARSession with a Metal renderer (no SceneKit/RealityKit). We measure drift directly from per-frame ARCamera.transform values, so the displacement appears in ARKit's pose output itself rather than in any rendering layer. The drift accumulates with walking distance and does not occur when the device is stationary. We've observed this across a large variety of devices (iPhone 15/16/17 Pro/Pro Max) on all iOS versions 26.4 or greater. We've also observed this on iPad Pros with updated firmware. Thread 827240 additionally reports that disabling autofocus, HDR, and plane detection and varying scene reconstruction and world alignment did not resolve it. Question Because depth capture is our core function, we cannot avoid engaging the LiDAR scanner, and we're not aware of a public API that adjusts its contribution to world tracking. We'd be grateful for guidance on three questions: Is this a known issue in iOS 26.4 and later? Did the LiDAR contribution to world tracking change in that release? For apps that require sceneDepth, is there any recommended session configuration, video format, or capture-side practice that reduces the drift in the interim? Is a fix planned, and if so, should we expect it in an iOS 26.x update or the iOS 27 cycle? This affects how we manage our deployed device fleet. We're happy to provide trajectory datasets, additional sysdiagnoses, or anything else useful. We have quantified drift-per-distance data across OS versions.

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!

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’d be very interested in having Apple Cinema Environment deployed across all third party apps (I.e Disney+, HBO Max, etc). These already have their immersive environments as well as the option to use Apple’s immersive environments (i.e the Moon). However the Apple Cinema / Theater is the best implementation I’ve seen thus far however its currently limited to the AppleTV content. Are there any plans to deploy this across other apps?

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

I'm attempting to create GeometricPins on an entity so I can attach objects to game characters. If I load a character from the USD file I can query the joint names on the ModelEntity and create GeometricPins as attachment points. These pins will track the location of the associated joint and I can position my objects at the pin locations as expected. However, the pins do not update on characters loaded from a Reality File. In the below image, the Skeleton Mage character in the middle is loaded as a USDC file and I attach the hat with a GeometricPin so that it tracks the movement of the head as it animates. The animating Skeleton to the left is the same character (same .usdc file) but exported from RCP3 as a Reality File. Notice how the hat does not move with the character's head. The position and orientation of the GeometricPins attached to this character always return nil. I've also noticed that the jointNames array is empty for this entity as well. Should I be able to access the jointNames and create Geometric pins on entities loaded from Reality files? I'm adding the pin to the model entity with the following helper function. The helper function is called in the exact same way for the usd and reality entities. func pinToJoint(_ entity: Entity, to target: Entity, at jointName: String, offset: SIMD3<Float> = .zero, orientation: simd_quatf = .init(angle: 0, axis: [0,1,0])) { let pinName = "pin_at_\(jointName)" if let rig:ModelEntity = target.findModelEntity() { for jointName in rig.jointNames { log.info("\(target.name): \(jointName)") } rig.pins.set(named: pinName, skeletalJointName: jointName, position: offset, orientation: simd_quatf(angle: -.pi/2.0, axis: .init(1,0,0))) entity.components.set( PinnedEntityComponent( pinnedto: rig, pinName: pinName, ) ) } } The PinnedEntitySystem just assigns the location of the pin to the entity with the following guard let pinPosition = pin.position(relativeTo: nil) else { continue } guard let pinOrientation = pin.orientation(relativeTo: nil) else { continue } entity.setPosition( pinPosition , relativeTo: nil) entity.setOrientation( pinOrientation , relativeTo: nil)

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.

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

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.

My project environment must be in mixed mode. When I use code to control OpacityComponent to fade Entity in and out, occasionally the gradient model outline area will appear with video penetration. What is the reason and how can it be resolved?

There is a UI panel with Attachment added in my scene. There are other models in the scene, and when the model fades in using OpacityComponent, the UI panel incorrectly displays the outline of the model, as shown in the red box in the picture. The model fade in code is like this: public func FadeInEntity( entity:Entity, duration: TimeInterval = 1.0, completion: (() -> Void)? = nil ) { entity.stopAllAnimations() if entity.components[OpacityComponent.self] == nil { entity.components.set(OpacityComponent(opacity: 0)) } else{ entity.components[OpacityComponent.self]?.opacity = 0 } EnableEntity(entity: entity) let action = FromToByAction<Float>( from: 0, to: 1, timing: .easeInOut ) do { let anim = try AnimationResource.makeActionAnimation( for: action, duration: duration, bindTarget: .opacity ) entity.playAnimation(anim) DispatchQueue.main.asyncAfter(deadline: .now() + duration) { completion?() } } catch { completion?() } }

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 did get an email that I now have access to the Enterprise APIs and I should create the license file. However, I can't figure out a way to create the license file. I did go check out that button, it did have the buttons to "renew" the licenses I got a while ago (via email). but no way to create new ones. and I am enrolled in the "Apple Developer Program as an organization " Where can I create Enterprise.license file?

FB24108671 I have multiple animation files and characters that all share the same skeleton definition. This is required in order for the animations to be visible in the animation library. However, you can accidentally delete the import that contains the skeleton definition, this will break every animation that depends on that shared skeleton. This is silent until you attempt to play or inspect one of the remaining animations. To my knowledge, there is no indication as to which Import contains a skeleton definition nor is there a way to lock the file so that I cannot delete it. Repro Steps: Create a new RCP3 project and save the project. Import a USD file that contains a skeletal animation. Import one or more additional USD files that contains also contain skeletal animations. Note: The skeletons must match exactly between the imported USD files or they will not be available in RCP3. Verify that all imported animations have a valid target Skeleton. This is visible by clicking on an Import and expanding the Animation Settings section in the inspector. Select the skeletal animation and view the Target Skeleton field. Optional: Import a USD file that contains a character with a matching and valid skeleton. Create a new entity and reference the imported character. Add a new Animation Library and confirm that the skeletal animations appear in the list of available animations. Select one of the animations to auto play and hit the play button to simulate the animation. The animation should play. Open terminal and navigate to your saved RCP3 project. In the root of the project run the find command to locate the skeletal definition NullTruthDeletedAnimation.realitycomposerpro % find . -name '*.tm_skeleton_definition' ./animations/Running_B.import/skeletons/root_skeldef.tm_skeleton_definition Back in RCP3 delete the Import that contains the skeleton definition. In the above case, this would mean deleting RunningB.import. Save the RCP3 project. All animations that were assigned to the same Target Skeleton will now have an empty entry in the Animation Settings section of the inspector. If you created an entity earlier that referenced the animations then none of the animations that referenced the delete skeleton will play. In the console you will see an error reporting a missing timeline. ❌ GEN RESOURCE: tm_timeline_skeletal_clip object id: 00002dab0000024c - Resource generation failed. Error: Animation Timeline is missing a target skeleton If you assigned the deleted animation to this entity then it will still have an entry in the animation library but its value will be empty. After saving the project, close and reopen the RCP project. If you created an entity earlier, then open the created entity and simulate the scene. You may see the following errors. ❌ GEN RESOURCE: tm_timeline_skeletal_clip object id: 00002dab0000024c - Resource generation failed. Error: Animation Timeline is missing a target skeleton (2) ❌ error: Trying to lookup property of NULL truth object ❌ GEN RESOURCE: tm_timeline object id: 000023a700000248 - Resource generation failed. Error: Sampled USD anim - missing TM_TT_TYPE__ANIMATION dependency The GEN RESOURCE: tm_timeline_skeletal_clip object id error appears to be due to the broken animation library entry for the deleted animation. The error: Trying to lookup property of NULL truth object error appears to be the animation referencing the deleted skeleton. If you did not create an entity then you can see the errors by doing the following: Select one of the imported animations that referenced the now deleted skeleton. In the Inspector, expand the Animation Settings section. Select the skeletal animation, you will now see the following error repeating in the console. ❌ error: Trying to lookup property of NULL truth object ❌ (previous error repeated 59 times) ❌ error: Trying to lookup property of NULL truth object ❌ (previous error repeated 53 times) ❌ error: Trying to lookup property of NULL truth object ❌ (previous error repeated 59 times) You can fix this by importing a new animation with a valid and matching skeleton or reimporting the deleted animation. However, you MUST manually assign the Target Skeleton on each broken skeletal animation. You will also need to manually remove any animation library entries for deleted animations.

On visionOS 27 (27.0 Seed 4, 24M5326g), adding a ManipulationComponent to a single entity makes RealityKit remove the RealityView's ENTIRE content hierarchy from the scene and re-add it about 30ms later. Not just the manipulated entity — everything. Same app binary on visionOS 26: never happens. FB24092291. Bisected on the same build and device: two entities, neither with manipulation -> no detach add one entity with a ManipulationComponent -> detach, every time same entity, manipulation swapped for my own drag/rotate/ scale gesture handling -> no detach Everything else is identical between the last two cases — same entity, same collision shape, same InputTargetComponent, same ViewAttachmentComponent, same scene, same view hierarchy. The only variable is whether the component is installed. Setup: an immersive space containing a SwiftUI RealityView. One root entity added to the RealityViewContent in the make closure; all app content built as its descendants. The detach is brief but not harmless: every entity in the hierarchy gets SceneEvents.WillRemoveEntity and then DidAddEntity, so anything keyed to those events runs a full teardown and re-add for content that was never meant to go anywhere. In my app that cascade is what makes the scene visibly empty and rebuild. Nothing in my code removes it. Stack captured from a WillRemoveEntity subscription on the root — frame 0 is my callback, everything above it is framework: SwiftUI (AttributeGraph StatefulRule.withObservation ...) -> RealityFoundation -> CoreRE -> entity removal Ruled out before landing on the component: make runs exactly once, the root re-enters a scene with the same ObjectIdentifier (not a re-host), the hosting controller is never deallocated, there is exactly one RealityViewContent.add(_:) in the whole app, and with Self._printChanges() in the view's body the detach happens in an update pass where the body is not re-evaluated at all. Also ruled out: transient overlay UI (suppressed entirely, still detached) and entity count. Workaround if this is biting you: skip ManipulationComponent on 27 and handle drag/rotate/scale yourself. That is what I am doing for now. If you are debugging something similar: SceneEvents.WillRemoveEntity also fires when an entity merely leaves a scene, so a teardown-looking log is not proof anything was destroyed. Check whether make ran twice and whether the scene identity changed before suspecting your own code.

First of all, great work on the new Reality Composer Pro! I'm really enjoying it. Reality Composer Pro 3.0 (build 80.0.1.500.1/beta 4) currently shows GPT-5.5 as the newest OpenAI model in the Assistant model selector. The bundled configuration appears to contain a static model catalogue and does not include: gpt-5.6-sol gpt-5.6-terra gpt-5.6-luna Could Apple update Reality Composer Pro to support the current GPT-5.6 model family, or document whether users can add supported OpenAI model identifiers through the Custom Model Provider interface? It would also be helpful to clarify whether the Assistant supports GPT-5.6's tool-calling and reasoning behavior through its current Chat Completions integration. Thanks!