An incomprehensible error occurs whenever I try to access Main Camera features. I have already acquired the Main Camera entitlement and granted the required permissions, yet the error persists. To make matters worse, even Apple’s provided sample code triggers the exact same issue. The error message is far too uninformative to diagnose the root cause, and I urgently need a resolution as this is completely blocking progress. Multiline [C:1-2] Error received: Invalidated by remote connection. failed to observe with mask <BLSXPCBacklightProxyObserverMask: 0x108accf80; didUpdateToState: YES; eventsArray: YES> error:<XPC error received on message reply handler (3:BSServiceConnectionErrorDomain) "The operation couldn’t be completed. XPC error received on message reply handler"> non-launching port is incompatible with service identifier "com.apple.PointerUI.pointeruid.default-service" nw_socket_copy_info [C1:2] getsockopt TCP_INFO failed [102: Operation not supported on socket] nw_socket_copy_info getsockopt TCP_INFO failed [102: Operation not supported on socket] Unable to find a compatible slice for binary archive at /System/Library/Frameworks/CoreImage.framework/ci_uberwrapper_bin.metallib *** Assertion failure in void ar_session_request_authorization(ar_session_t _Nonnull, ar_authorization_type_t, __strong ar_authorization_results_handler_t _Nonnull)_block_invoke(), session.m:1491, reason: This app failed to request an authorization. The NSWorldSensingUsageDescription / NSHandsTrackingUsageDescription / NSAccessoryTrackingUsageDescription / NSMainCameraUsageDescription keys may be missing from this app's Info.plist. <NSXPCConnection: 0x10e68dcc0> connection to service with pid 86 named com.apple.arkit.service.authorization: Exception caught during invocation of reply block to message 'requestAuthorizations:withReply:'. Exception: This app failed to request an authorization. The NSWorldSensingUsageDescription / NSHandsTrackingUsageDescription / NSAccessoryTrackingUsageDescription / NSMainCameraUsageDescription keys may be missing from this app's Info.plist. ( 0 CoreFoundation 0x0000000198b756d4 686CE4EB-CE52-3DD5-8B23-EF6A6BBFACEA + 1205972 1 libobjc.A.dylib 0x000000018d3a71cc objc_exception_throw + 88 2 CoreFoundation 0x0000000198b755c0 686CE4EB-CE52-3DD5-8B23-EF6A6BBFACEA + 1205696 3 ARKitCore 0x00000002bbd640cc 53FDDDD4-8DD1-3E86-ACB0-8867D29AF781 + 479436 4 CoreFoundation 0x0000000198b7c5b4 686CE4EB-CE52-3DD5-8B23-EF6A6BBFACEA + 1234356 5 CoreFoundation 0x0000000198b79558 686CE4EB-CE52-3DD5-8B23-EF6A6BBFACEA + 1221976 6 Foundation 0x000000019de4220c 61E78A52-3B44-3DCE-AF6D-92C33FA0FACA + 2109964 7 Foundation 0x000000019de41dd0 61E78A52-3B44-3DCE-AF6D-92C33FA0FACA + 2108880 8 Foundation 0x000000019de4651c 61E78A52-3B44-3DCE-AF6D-92C33FA0FACA + 2127132 9 libxpc.dylib 0x00000002c43d5a00 CE0BB604-B358-3F22-B1DA-FFACEFCA20AD + 150016 10 libxpc.dylib 0x00000002c43c5678 CE0BB604-B358-3F22-B1DA-FFACEFCA20AD + 83576 11 libdispatch.dylib 0x00000002c41045fc 4CF750D7-AC3B-3175-9863-2F059D3D3715 + 108028 12 libdispatch.dylib 0x00000002c41083ec 4CF750D7-AC3B-3175-9863-2F059D3D3715 + 123884 13 libdispatch.dylib 0x00000002c40f37c0 4CF750D7-AC3B-3175-9863-2F059D3D3715 + 38848 14 libdispatch.dylib 0x00000002c40f4450 4CF750D7-AC3B-3175-9863-2F059D3D3715 + 42064 15 libdispatch.dylib 0x00000002c40fe3ec 4CF750D7-AC3B-3175-9863-2F059D3D3715 + 82924 16 libdispatch.dylib 0x00000002c40fdd18 4CF750D7-AC3B-3175-9863-2F059D3D3715 + 81176 17 libsystem_pthread.dylib 0x00000002c4364e34 _pthread_wqthread + 292 18 libsystem_pthread.dylib 0x00000002c4362910 start_wqthread + 8 ) *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'This app failed to request an authorization. The NSWorldSensingUsageDescription / NSHandsTrackingUsageDescription / NSAccessoryTrackingUsageDescription / NSMainCameraUsageDescription keys may be missing from this app's Info.plist.' *** First throw call stack: (0x198b756c8 0x18d3a71cc 0x198b755c0 0x2bbd640cc 0x198b7c5b4 0x198b79558 0x19de4220c 0x19de41dd0 0x19de4651c 0x2c43d5a00 0x2c43c5678 0x2c41045fc 0x2c41083ec 0x2c40f37c0 0x2c40f4450 0x2c40fe3ec 0x2c40fdd18 0x2c4364e34 0x2c4362910) *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'This app failed to request an authorization. The NSWorldSensingUsageDescription / NSHandsTrackingUsageDescription / NSAccessoryTrackingUsageDescription / NSMainCameraUsageDescription keys may be missing from this app's Info.plist.' *** First throw call stack: (0x198b756c8 0x18d3a71cc 0x198b755c0 0x2bbd640cc 0x198b7c5b4 0x198b79558 0x19de4220c 0x19de41dd0 0x19de4651c 0x2c43d5a00 0x2c43c5678 0x2c41045fc 0x2c41083ec 0x2c40f37c0 0x2c40f4450 0x2c40fe3ec 0x2c40fdd18 0x2c4364e34 0x2c4362910) libc++abi: terminating due to uncaught exception of type NSException Xcode has killed the LLDB RPC server (pid: 2210) to allow the debugger to detach from your process. BlockQuote visionOS 27 beta 5

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.

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!

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

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

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.