There are two independent frame rates, only one of which (afaik) can be measured from Unity. You can inspect them both though using Xcode Instruments profiler. When you open Instruments, start a new profile and choose “RealityKit Trace” profiling template.
The top section shows “RealityKit Frames” which is the framerate of the device’s fully composed render, including other applications and system UI.
Although each frame here is around 12.6ms, they are pipelined, and if you measure the frame-to-frame time you can see it’s hitting 11ms as required for 90 FPS.
The green color-coding also indicates that the frame was completed within the required time – sometimes the system will slow down the framerate deliberately, but this is not due to a performance issue:
All of the above CPU and GPU measurements are from the “backboardd” system process which is actually compositing your game with the rest of the system. Your code is not actually running here, but if you have complex geometry or shaders then you could possibly see a slowdown here (seems unlikely if you’re getting 180 FPS in editor).
Your actual Unity code is running in a separate process and is shown in the Runloops section:
In the above image each runloop iteration is easily completing within the 11ms, so it’s keeping up with the system framerate. However, even if it takes longer (for example, your CPU cost is too high in your Unity code), that doesn’t affect the system framerate:
The long Main Thread iteration here is 18ms, but the system doesn’t wait for it to complete before it renders its own frame, which is how it generally keep up a 90 FPS for the sake of good head-tracking even if your Unity app is running at a lower framerate, or having hitches like this one.
Enable high-frequency sampling in the Time Profiler options to identify the causes of the high CPU cost (or examine the GPU tracks I haven’t mentioned if you’re GPU-bound).
