Hello, In the past my apps using animations were unable to use multiple animations. Following online guides, I put together sequences of animations and then used timestamps to playback the animation I wanted. Is there any intention for realitykit to support better selection of animations within our entities? Its somewhat of a limiting factor in what I am willing to do within reality kit. Thanks for the improvements to realitykit

RCP 3 Script Graphs in 27.0 appear to be JavaScript-backed and hot-reloadable. SceneKit historically exposed its scene graph to JavaScript via JavaScriptCore, so Apple has bridged a 3D framework to JS before. Questions about the runtime surface: Is there a public runtime API to evaluate JavaScript against a RealityKit scene, or to drive Script Graph behavior programmatically at runtime — or is the JS layer private SPI used only by RCP-authored, baked graphs? If there's a runtime JS layer, what object model is exposed — which entity/component types are bridged, and is that surface documented or intended to become public? What's the hot-reload mechanism, and is it reachable outside RCP's Preview on Device? Can a script graph be constructed or parameterized at runtime from a string, or is authoring strictly RCP-side with baked output loaded as an asset? We ship JavaScript scripting via JavaScriptCore ourselves, so a public RealityKit-to-JS binding would be a natural way to extend it — trying to understand what's public vs. private and the intended direction.

Currently VisionOS has WorldAnchors which are a great, privacy-preserving method to affix and localize entities into physical spaces. These are great for apps that work in Mixed immersive mode as well as augmented layer or virtual overlays onto physical spaces. However, they have some fundamental limitations when compared to iOS’s ARWorldMap which limit their capabilities as truly persistent WorldAnchors, which the platform would greatly benefit from. The problem - Impermanence: WorldAnchors are on-device only, stored in data at a system level and expose their ID for collection and usa within apps. If the app which created them is removed, or if the device is rese, those saved World Anchors are removed and lost forever. Their ID will no longer point to an anchor in physical space and it is as if the anchor has been deleted or never existed. This means that anchors effectively only temporarily exist on a single device while that specific device is in an undisturbed state. A second device using that same app with interest in utilizing that anchor is not available. With no way to export this Anchor, save it, re-load it either inside an app bundle, from a server, on-site data storage, etc. the anchor is 'trapped' on the device which creates it. ARWorldMap can be saved to a file, and acquired in many ways which circumvents this problem, and allows it to exist as a single source of truth for that particular physical environment that any iOS or iPadOS device can localize to as long as they have the ARWorldMap. Imperfect Workaround #1 - SharedAnchors: After setting a WorldAnchor on Device #1, start a local S harePlay session with Device #1 & #2 in the same physical space. Then, use a 'Shared Anchor' with transform offset data matching the WorldAnchor. On Device #2, save that offset as a new WorldAnchor. This new WorldAnchor will have the same transform effectively matching the original, though it will have a new ID and is entirely separate. Problem with Workaround #1: This requires two VisionOS devices to be in the same physical location simultaneously, have an active SharePlay session between the two devices, then conduct a sharing operation. This means that if Device #1 does not happen to be available in the physical space at the same time as Device #2 for any reason, Device #2 will never have access to this anchor. In cases such as a public or industrial space, it is not realistically viable to always have a person with Device #1 available at all times. There are many situations where Device #2 would want to enter the space and observe the anchor while they are alone, and would never have access to this anchor. Workaround #2 - iOS / iPadOS Middleman: Once a visionOS WorldAnchor is created on Device #1, that same user can manually co-locate an iOS or iPadOS device, with some shared session (for example, using ImageTrigger on the iOS/iPadOS device's display which the visionOS device reads, then determines an offset for). Then, create an ARWorldMap on that co-located iOS/iPadOS device, and save it, then serve that ARWorldMap. Then to localize visionOS Device #2, enter the space and first localize an iOS / iPadOS device with the ARWorldMap. Then, manually co-locate visionOS Device #2 with the iOS/iPadOS device and access the offset. Then save this offset as WorldAnchor on Device #2, at this point the iOS/iPadOS device is no longer needed. Problems With Workaround #2: At a minimum, this requires 3 devices, or more realistically 4 if Device #1 and #2 are not in the space at the same time. This is not only a very poor user experience to have to operate an iOS/iPadOS device simultaneously while wearing visionOS device, but it is also very complicated and a several step process that is not intuitive to most users. The accuracy of this process is extremely poor, as tracking an image from the screen of an iOS/iPadOS device will never be as precise as the internal tracking system on VisionOS. It will always have SOME margin for drift and error, which can result in the anchor being very far offset from the intended anchor position. This is antithetical to the purpose of WorldAnchors, as the delta can be so inconsistent that Device #2 will observe content attached to the anchor at an incorrect location, which could lead to unintended user behaviour when interacting with this content potentially moving attached content to look correct for them, which would negatively impact all other devices viewing the content. Desired Solution: An optimal upgrade to visionOS WorldAnchors would; Use the same underlying tracking & relocalization system that is currently in use Allow for exporting of the WorldAnchor's data in an encrypted, privacy preserving way (not simply a point cloud) which could be saved and shared as a file similar to ARWorldMap, then used for relocalization on ANY device with access to that file and application. Be interoperable across platforms where iOS, iPadOS, visionOS and any other spatial-capable platform can use that single file, and localize themselves in the physical space. This would unify ARKit WorldAnchors for all platforms, ensuring that the same physical space can be localized to by all devices, anchors can be created by all devices, and the content would exist in the same position on all devices. Allowing an iOS or iPadOS device to create a WorldAnchor that is then identical on visionOS, or visa-versa. These features unlock true persistence in anchoring content to real-world spaces, a critical component of a Spatial Computing platform that maximizes the unique capabilities and benefits of the medium. This creates an upwards path for users to start on iOS / iPadOS today, and upgrade to visionOS in the future. Accessibility: Not all users are able to use visionOS for various reasons, including physical, regional and financial circumstances among many many others. There is no reason why someone who is unable to use visionOS for any one of these reasons should be LOCKED-OUT from Spatial Computing applications. Spatial computing is the most human computing medium ever created, and applications need to allow all humans to engage with Spatial Computing experiences regardless of their level of access to visionOS devices. We as developers want to build everlasting Spatial Computing applications that accentuate the medium, maximize the benefits of Spatial Computing, include / invite all humans regardless of their Accessibility level, and establish virtual content that can outlive the individuals who create it. Please, take this request into serious consideration, as the feature as described would contribute to the Apple Ecosystem being the single greatest Spatial Computing platform of all time (and space), enabling permanent layering of physical spaces, preserving privacy for sensitive data, and maximizing accessibility across the spectrum of humans and devices. Thank you.

I’m using Reality Composer Pro 3 for a visionOS project, and I have a question about the editability of Shader Graph and other node-based systems. In RCP, Shader Graphs and other node graphs can be created and edited visually in the editor. I would like to know whether these graphs also have a supported code-based or text-based editing workflow. Specifically: Is there a public, documented file format for Shader Graphs in Reality Composer Pro 3 that developers can edit directly outside the RCP GUI? Can Shader Graph nodes, connections, parameters, and materials be generated or modified through code, scripts, or text files in a supported way? Does the same apply to other node graphs in RCP, such as behavior graphs or animation-related node graphs? If these graphs are stored internally inside the Reality Composer Pro project package, is it safe or supported to edit those underlying files directly? If direct editing is not supported, is there any recommended workflow for version control, reuse, templating, or programmatic generation of similar Shader Graph setups across multiple assets? My reason for asking is that I’m trying to build a more scriptable asset pipeline. For models and scene structure, it is often practical to generate or modify content through code. However, for complex Shader Graphs or node graphs, manually rebuilding similar node setups in the GUI can become repetitive and difficult to maintain. I’m not asking about private or unsupported internal formats. I’d like to understand whether Apple currently provides, or recommends, any supported workflow for code-driven editing, generation, reuse, or version control of Shader Graphs and other node graphs in Reality Composer Pro 3. Any guidance would be appreciated.

I have a question about material authoring improvements in Reality Composer Pro 3, especially for transparent or refractive PBR materials. In Reality Composer Pro 2, I found it difficult to create convincing glass-like materials. For example, the available Shader Graph nodes seemed limited for this use case, and I could not find common controls or nodes that are often useful for glass and crystal materials, such as Fresnel-style effects or more direct refraction-related controls. I would like to understand whether Reality Composer Pro 3 has improved this area. Specifically: Does Reality Composer Pro 3 provide better support for realistic glass, crystal, acrylic, or transparent PBR materials? Are there new Shader Graph nodes or material controls that help with Fresnel-style edge reflections, angle-dependent transparency, or similar effects? Does Reality Composer Pro 3 support index of refraction / IOR controls for transparent or refractive materials? Is there any supported way to create real refraction or physically plausible transmission for glass-like materials in RCP 3? If true refraction or IOR control is not supported, what is the recommended approach for creating convincing glass, crystal, or polished transparent materials for visionOS apps? Are there any sample projects, documentation pages, or WWDC sessions that show the recommended material setup for glass-like surfaces in Reality Composer Pro 3? My goal is to create visually believable glass and crystal-style materials inside the standard visionOS / RealityKit rendering pipeline, preferably using supported RCP material tools rather than unsupported shader workarounds. Any guidance on the current capabilities and recommended workflow in Reality Composer Pro 3 would be appreciated.

If I open a regular 2D window or a volumetric window while the ImmersiveSpace is active, is there any supported way for that window or volume to receive lighting from the immersive scene? For example, if I have lights, environment lighting, or other lighting setup inside the ImmersiveSpace, can those lights affect the content of a 2D window or a volumetric window opened by the same app? Or are windows, volumes, and immersive spaces rendered with separate lighting contexts? I’d like to understand the recommended approach if I want UI panels or small 3D volumes opened during an immersive experience to visually match the lighting of the immersive environment.

Hello from WWDC26! After installing visionOS27, USDZ models that viewed properly now exhibit strange anomalies, especially around UV seams. See attached image. Thx!

Is it possible to utilize exr light maps rendered externally, for example in Blender, in Reality Composer Pro 3? I am thinking there might be a light map node in the material graph editor, that uses the same mixing modes as internally generated light maps, allowing workflows where light maps are rendered externally.

I seek advice on converting 3-D TIFF volumes, typically (1k)^3 16-bit unsigned integer, into guided and unguided Apple Vision Pro displays. My background is Mathematica (Wolfram) and ImageJ/Fiji applied to datasets collected at facilities such as the Advanced Photon Source at Argonne Natl. Lab. By guided, I mean a student/teacher situation such as used by MassVirtual to train aircraft mechanics and the chemistry software Nanome. By unguided, I mean the shared VR environment used by Shapr3D. For medical data, my current workflow is DICOM->Wolfram->Blender->Freeform, all on a Mac, then iCloud transfer of Freeform from Mac to Vision Pro. It works, but seems there should be something better. Suggestions?

Am I correct to understand that visionOS 27 brings the Vision API to the headset? What are the privacy restrictions on its use?

I'm building a MR teleoperation app for the Apple Vision Pro. Instead of 2D camera feeds, I render the robot's remote workspace as 3D Gaussian splats, so the operator can perceive depth and inspect objects from any angle by moving their head. That means the operator needs to lean in close to an object, and sometimes move the viewpoint right up to or through it, without the object dropping out of view. Right now when I use the visionOS 27 splat sample out of the box, the splats disappear when the operator gets too close. As the viewpoint approaches a splatted object the entire splat will vanish. This can be solved partially with chunking the splats, but the operator still can't move inside the splat itself. The entire splat vanishing, and chunking helping, makes me think the splat entity is culled once the camera enters its bounds, rather than individual Gaussians being clipped at the near plane. I don't know the renderer's internals, so I may be wrong about the cause. I believe the sample renders in an ImmersiveSpace, not a bounded volume. Does GaussianSplatComponent expose any control over how splats are culled up close (near plane, clipping, or entity bounds), so the splat stays visible as the viewer moves close to or inside it? If there's no such control today, is there a recommended way to let the viewer move through a splat without it disappearing?

We're building animated and streamed Gaussian splat playback into Scenery, our native Apple AR/spatial authoring platform, and have a few questions about the intended usage of GaussianSplatComponent / GaussianSplatResource. Dynamic / animated splats (4D) Is mutating the underlying LowLevelBuffer behind a BufferResource at runtime a supported pattern, or is the component intended for static captures? BufferResource's init is @MainActor and the resource's bufferResource property is let, which suggests static intent. For animated (4D) splats, do we need to wrap a new BufferResource each frame and reassign it, or will in-place writes to the existing buffer be picked up by the renderer? If re-wrapping is required, is there a recommended cadence, and does it trigger a full re-sort/re-upload internally? LOD streaming / swapping Related: for streaming splat LOD, is swapping the BufferResource (or its buffers) at runtime supported, and is there a cost model we should design around — e.g. does a swap re-sort and re-upload everything, or can partial updates be done? Splat-count limit The BufferResource initializer throws past an internal limit (we're seeing ~200k). Is this limit fixed, memory-derived, or per-device? Is it per-component or per-scene — i.e. can we tile a large capture across multiple GaussianSplatComponents to exceed it? Any guidance on the intended ceiling and whether it's expected to change? Large captures as immersive environments We'd like to use a large splat capture as an environment the user walks inside (camera within the splat volume), rather than an object viewed from outside. Is this an intended use case? We're seeing splats appear to fade/break up as the camera gets very close — is that near-plane behavior, an opacity falloff, or the projection breaking down at close range, and can it be controlled? Does ProjectionMode.tangential help for inside-the-volume viewing? Thank you and appreciate the great updates!

I'm trying to create a hexagonal triplanar material in Reality Composer Pro 3 using Shader Graph. Could you provide guidance, or an example node setup, for creating a seamless hex-tile texture using triplanar projection? My goal is to apply a hex pattern to 3D objects without visible seams or texture stretching. Are there any sample projects, Shader Graph examples, or recommended workflows for achieving this in Reality Composer Pro?

This is a very general and high level question. I am working on an app that scans buildings using on device LiDAR. One of my biggest issues is drift over time. What is the recommended approach by Apple to successfully scan for a long period of time and reduce drift error? I am currently storing frames at 20 fps with pose data and then trying to correct for pose errors off device. Maybe my approach is incorrect and would like to understand how Apple recommends to do about this. I am being overly general on purpose. Thank you for your help.

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

We are building an ARKit application targeting iPhone Pro devices on iOS 26.4+. During testing, we consistently observe the following log message at a specific point in our AR session (approximately 90° into a walking arc around a vehicle): ARWorldTrackingTechnique: resource constraints [33] What specifically does resource constraint code [33] represent? Is it a VIO constraint type, a sensor fusion budget limit, or something else entirely? How does it differ from code [1] (which appears to be a general CPU starvation signal for the ARKit sensor fusion thread)? Is there a public API to detect or respond to this specific constraint condition, short of waiting for a full ARCamera.TrackingState downgrade? Was this constraint type introduced or changed in iOS 26.4?

I'm trying to create a hexagonal triplanar material in Reality Composer Pro 3 using Shader Graph. Could you provide guidance, or an example node setup, for creating a seamless hex-tile texture using triplanar projection? My goal is to apply a hex pattern to 3D objects without visible seams or texture stretching. Are there any sample projects, Shader Graph examples, or recommended workflows for achieving this in Reality Composer Pro? Thanks

For Vision Pro's tiled GPU, how does MeshInstancesComponent compare to manually merging meshes for draw-call reduction? Does it collapse draw calls similarly while still allowing per-instance transform and material variation? Deciding whether to re-architect a heavy interior scene around it instead of hand-merging in Maya.

RCP 3's Animation Graph covers state machines and blending of imported clips. As an animator, is there now any in-editor support for authoring or editing animation curves and keyframes directly — a graph editor or dope sheet — or must all keyframe animation still be authored in a DCC (Maya/Blender) and imported as clips?

RCP 3 adds a lot of artist-facing surface: lightmaps, Animation Graph, Script Graph. Are step-by-step, artist-oriented tutorials planned beyond the API reference docs? A guided onboarding path would help 3D artists adopt these features much faster.