Threadgroup operations with memory_order_relaxed for atomic_uint values have been available for a very long time—nothing changed for those that I’m aware of in Metal 4. What’s new in 4.1 in this area is additional memory-order options (see section 6.16.1 in the MSL spec) and threadgroup add/sub for atomic_float values (see the end of section 6.16.4, right before Table 6.27). If you’re not using either of those, which it sounds like you aren’t, then your min-spec for this stuff is probably somewhere around Metal 1.

You no longer need to set the depth format ahead of time; you can just supply a depth texture when setting up your render pass later on.

I don’t see anything obviously wrong with your code. Depending on the size of your scene and how things are positioned, it could be an issue with your projection matrix’s “far” distance being too close, which would cause anything beyond (currently) 10 units to get clipped away. Can you share a screenshot of what “80%” looks like? Does it change as you move the camera?

Most of those look normal—if the volume of logging is a problem for you, please file RealityKit feedback. The last one (makeRenderPipelineState failed) might indicate an actual error; it would be worth checking whether your AR content is successfully casting shadows on the real-world environment, and if it’s not, definitely file feedback about that 🙂

You can definitely do the raymarching part, but you’re right about there not being a way to output a custom depth value in a surface shader. If this is on a non-visionOS platform, you could try drawing your SDF in a full-screen post-processing pass with ARView’s PostProcessContext, which would give you access to the depth buffer produced by the rest of your scene to blend with as needed.