Push. This issue is present unchanged in macOS 27.2 Beta. Pretty bad user experience.

The issue is unfortunately still present in iOS 27.2 Beta 1. Please consider prioritizing it. The feature is unusable in the current state outside of visionOS.

This seems to be finally fixed in the just released iOS 27.2 Beta. 🎉 Thank you!

@DTS Engineer thanks for your reply! Sent a sample project to DTS via FB24091347. Building it changed what I thought this bug was. It needs a RealityKit view on screen. My sample is two SwiftUI ScrollViews either side of a centre view, with a segmented control that swaps the middle between nothing and a RealityView. Built-in panel on ProMotion: scrolling judders with the RealityView there, smooth without it. I can toggle it back and forth and it flips every single time. I tried to pin it on continuous rendering in general and couldn't. An MTKView drawing a triangle at 60 was smooth. At 120, smooth. On a 120 Hz display link presenting every second callback, smooth. So it isn't just any view presenting continuously, and it isn't the frame rate being asked for. Since RealityView is backed by ARView, testing both gets you the same answer. The display side still makes no sense to me. The built-in panel's refresh rate setting decides whether a window on a different display judders. ProMotion on the built-in, window on my 60 Hz Studio Display: judder. Drag that same window to the built-in: smooth. Unplug the Studio and the built-in judders. Set the built-in to 60 Hz and everything is smooth everywhere. I also attached two videos recording the judder, one in 240FPS SlowMo. Please let me know if you need anything else or can recommend any workarounds. Thanks again!

This is still not fixed in Beta 6 and I am starting to fear it won't also be for GM. Makes for a terrible user experience compared to macOS 26. Are there any recommended workarounds? I do have a RealityKit ARView in my view hierarchy wrapped as a UIViewRepresentable, but again; it works fine on macOS 26. It's a Mac Catalyst app using a mix of UIKit and SwiftUI.

Updated my radar with a sample project that instantly reproduces the issue on Beta 5 @DTS Engineer.

The issue is still present in iOS 27 Beta 5 and related.

The issue is still present in iOS 27 Beta 5 and related.

Solved. Two things together cause it: .focusable() + .focused($isFocused) on the SwiftUI container holding the WKWebView. The app echoing the page's focus reports back into that state — page posts on focus/blur, app sets isFocused = true/false. Either alone types fine. A single focus drive at load does not reproduce; it has to be the echo. A plain is enough — not Monaco-specific. Fix: if #available(iOS 27, *) { content } else { content.focusable().focused($isFocused) } Correcting myself: a workaround does exist, and my earlier claim that -becomeFirstResponder re-arms an endless loop was measured with .focusable() still applied, so treat it as unverified. FB24092251 has a standalone repro project attached.

Severity depends on the camera type, not on the platform. With a virtual camera (RealityView, content.camera = .virtual, .realityViewCameraControls(.orbit)) the lag is severe and identical on iPhone and on macOS / Mac Catalyst — this is not a Catalyst quirk. In world-tracked AR (content.camera = .spatialTracking) it is noticeably milder. Both checked in the same build of the attached reproducer, which now has an Orbit / AR switch on iOS. I report the AR difference as an observation only — I have no evidence for why the two differ. Either way, the worst-affected case is the virtual camera, which is what any non-AR 3D viewer on iOS and macOS uses.

Thank you @DTS Engineer! Good to know the visible set isn't exposed and I'm not missing a property. I'll keep retesting on each beta and updating FB23749559 with the results. The report also has a screen recording attached showing the pull-back with no recovery followed by recovery on camera move, in case that's useful to whoever picks it up.

@Vision Pro Engineer This fully answers the architecture question — thank you. Custom Metal surface shaders on visionOS with foveation + CompositorServices interop is exactly what we needed to hear, and the LowLevelTexture → ShaderGraphMaterial route (with the tessellated-grid geometry-modifier trick for approximate depth) is clear. The one thing that'd be transformative for us: a first-class way to render LowLevelRenderer content inside an existing RealityKit scene with shared depth — true mutual occlusion against normal entities, rather than texture-on-a-mesh with approximated depth. Filed as a feature request, FB23042990 — essentially a "LowLevelRendererComponent" or a render-callback hook on RealityView. Our use case is mixing custom-rendered content (splats, custom Metal materials, dynamic meshes) with standard entities in one coherent scene on visionOS. Still very interested in the surface-shader ABI follow-up when you have it — the function signature contract (reserved vs. available buffer/texture slots, how camera/instance uniforms arrive, how LowLevelArgumentTable maps to argument indices), ideally with a pointer to sample code. Thanks again!

@Vision Pro Engineer This is great, thank you — exactly what we were hoping existed. We already ship our own JavaScriptCore-based scripting layer, and I've been digging through the package to understand how it'd fit alongside ours. Two questions the repo doesn't quite answer, both about deployment rather than API: Runtime location / .reality files. When a .reality file authored with scripts is opened in QuickLook or a system RealityView, what provides the runtime? Is RealityKitScripting OS-resident on 27+ (so system viewers execute embedded ScriptingComponents without each app or file bundling it), or must the consuming app link the package? I assume the .reality carries only the ScriptingComponent source string and the runtime must be present in the opening process — just want to confirm. Bundle size / App Clips. The GitHub release ships as an embedded binary xcframework. At GA, will it stay an app-embedded dependency, or become an OS framework apps link against? This matters for us because we target App Clips (size-constrained) and earlier OS versions, so we need to know whether adopting it means shipping the runtime or linking a system one. And one architecture question: is this the same runtime that RCP 3 Script Graphs execute on — i.e. does a type exposed via @Scriptable / TypeSchema become available to both text scripts and the visual graph? Thanks again — genuinely useful!

Also been filing feedback on this for a while — FB9381211 (filed 2021, still open), referencing the USD Preview Surface ior spec. For what it's worth on iOS: I've been faking refraction by grabbing the camera texture and doing a screen-space UV sample with an offset based on the surface normal. Works for the passthrough background, but the obvious limitation is it doesn't refract other virtual entities sitting behind the glass — the camera frame doesn't contain them. Would love to see first-party support for proper transmission as well!

Hitting the same limitation for cultural-heritage / environment captures where the viewer should be able to walk through the space. Filed FB23039893 covering this (camera-traversable splat volumes) plus runtime-mutable splat data.