After some testing, I was able to find a solution. The issue comes from the use of .tangents, which is deprecated in visionOS 2.0 and caused crashes in my RealityKit-based app. The correct approach now is to use drawable.computeProjection(viewIndex:) instead. Here's the working version of the updated code: return drawable.views.enumerated().map { (index, view) in let userViewpointMatrix = (simdDeviceAnchor * view.transform).inverse // New method to get the projection matrix let projectionMatrix = drawable.computeProjection(viewIndex: index) let screenSize = SIMD2( x: Int(view.textureMap.viewport.width), y: Int(view.textureMap.viewport.height) ) return ModelRendererViewportDescriptor( viewport: view.textureMap.viewport, projectionMatrix: projectionMatrix, // No need to wrap in `.init(...)` viewMatrix: userViewpointMatrix * translationMatrix * rotationMatrix * scalingMatrix * commonUpCalibration, screenSize: screenSize ) } This removed the deprecation warnings and resolved the crashes. It would be great if Apple improved the deprecation message for .tangents, especially since it currently says “use cp_drawable_compute_projection” which isn’t a symbol available in public APIs. Using computeProjection() is the actual method to can replace it.

Thanks for your detailed responses. After reviewing this closely, I realize the issue arises specifically from a compute pipeline implicitly dispatching threadgroups with a dimension of (32,32,1), exceeding the maximum allowed (832 threads per threadgroup) on Vision Pro devices. Following your suggestions, I've explicitly checked all compute pipelines in my project and verified the maxTotalThreadsPerThreadgroup property. However, I am not using MTLComputePipelineDescriptor; instead, I'm using MTLRenderPipelineDescriptor and MTLTileRenderPipelineDescriptor. I've ensured all my render shaders explicitly define threadgroup dimensions that comply with the maxTotalThreadsPerThreadgroup constraint, adjusting them to (16,16,1) to stay within safe limits. Despite these adjustments, the problem persists intermittently. Is there any known caching behavior or implicit threadgroup sizing performed by visionOS or Metal that could be causing the default value of (32,32,1) to resurface? Additionally, are there specific considerations or constraints for tile-based shaders or render pipelines in visionOS 26 compared to visionOS 2.0? Thanks again for your support!