I'm building an iOS game with RealityKit + Reality Composer Pro and was hoping to migrate to Reality Composer Pro 3. I created a new project in RCP and used the "link a new xcode project" flow. It built and rendered correctly on iOS 27. However, I encountered two issues when trying to build for iOS 26. The new RealityKitScripting package threw an error indicating <iOS 27 is not supported. I removed the related code, as I do not intend on using any Script Graphs. The iOS 27 scene still loaded correctly after removing this package. Are there any other consequences to removing this package other than not being able to use Script Graphs? Once the scene loading was working on iOS 26, I noticed that no materials built with the Shader Graph would render. Unlit and Physically Based materials render correctly, but Shader Graph materials do not. Even a simple Shader Graph with one Unlit material node input would not work. Is this expected behavior? My main question is, should I not expect to be able to use Reality Composer Pro 3 if I'm going to target an OS version <27?

Is there a supported route to automated regression testing of ARKit apps? Reality Composer's "Record AR Session" plus Xcode's "ARKit Replay data" scheme option work well for manual debugging, but replay isn't wired into XCUITest, doesn't run in CI, and ARKit doesn't exist in the simulator — so every AR regression today needs to be run by a human holding a device. Even replay-driven ARSession in the simulator, or an XCTest hook for selecting replay files, would unlock some automated coverage.

Is the website environment feature available on this first visionOS 27 beta? I am having troubles converting a web page that used the visionOS 26 website environment approach to the new visionOS 27 approach. Before I keep working on it, I would like confirmation that the feature is working. Also, does Apple have any web pages featuring a website environment that I can inspect?

SharePlay Connectivity Issue: Asymmetric Connection Failures Between Vision Pro Generations Environment: Device 1: 2nd generation Vision Pro Device 2: 1st generation Vision Pro OS Version: visionOS 6 build 23O471 Custom App Version: Both devices running identical version Both devices fully updated to the same OS and app versions Issue Description: SharePlay connections exhibit asymmetric behavior based on invitation direction, despite successful FaceTime connectivity between devices: 2nd gen → 1st gen: SharePlay invitation fails consistently 1st gen → 2nd gen: SharePlay invitation succeeds consistently. FaceTime calls: Successful in both directions Impact: Users cannot reliably initiate SharePlay sessions from newer generation devices to older generation devices. The issue is isolated to SharePlay functionality, as standard FaceTime connectivity works bidirectionally and both devices run identical versions of the custom app.

A few questions about the intended usage of LowLevelRenderer / LowLevelRenderContextStandalone for custom rendering (custom Metal materials, dynamic meshes, custom splat compositing): visionOS custom shaders in immersive space LowLevelRenderer is listed as available on visionOS 27. Does that include user-authored Metal surface shaders via makeSurfaceShader when rendering in an immersive space, or are custom fragment shaders restricted there the way CustomMaterial was? Any foveation / Compositor Services constraints we should know about? Composition with RealityView Is LowLevelRenderer (via LowLevelRenderContextStandalone) intended only for fully standalone/offscreen rendering where the caller composites the output, or can it inject draws into an existing RealityView's managed render pass? On visionOS specifically, what's the supported way to get its output onto the drawable alongside RealityKit-rendered content with correct depth interaction (mutual occlusion between custom draws and normal entities)? Custom surface shader ABI For makeSurfaceShader with a user-authored Metal function: what's the function signature contract? Specifically — which [[buffer(n)]] / [[texture(n)]] slots are reserved by the renderer vs. available to the caller, how do camera and per-instance uniforms arrive in the shader, and how do LowLevelArgumentTable bindings map to argument indices? A pointer to sample code or header documentation for the shader-authoring contract would be ideal. Hot reload / resource lifetime For an authoring tool that recompiles shaders frequently: can LowLevelRenderContextStandalone.Resources be rebuilt incrementally, and what's the cost of re-init via the synchronous init(resources:) path? Any guidance on reusing resources across context instances? Relationship to GaussianSplatComponent Is GaussianSplatComponent built on LowLevelRenderer internally? For 4D / animated splats and counts above the component's internal limit, is implementing custom splat rendering directly on LowLevelRenderer a path you'd recommend, or discourage? Thank you!

Safari, Freeform and some other apps now support curved windows. It this now available to developers as well? I couldn't find any information about it. Thanks!

I can’t complete assistant setup up in Reality Composer Pro 3 beta. I filled in the set up fields for OpenAI and clicked done. However, when I click connect nothing happens.

Can the new cloth sim be driven on a skinned character mesh — a cape pinned to the shoulders following skeletal animation — and does it run at interactive rates on visionOS, or is it aimed at non-real-time/hero content? Can a sim be cached/baked for deterministic playback?

The new GaussianSplatComponent: what's the supported ingestion path — standard .ply splats, .spz, or a conversion step inside RCP? And can a splat coexist in a scene with mesh geometry and depth-sort/occlude correctly against it, or are splats a separate pass with no depth interaction with meshes?

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?