macOS 27 beta: ProMotion refresh cadence is unstable, causing constant scroll judder

Question

Created 3w

Replies 4

Boosts 0

Participants 2

FB24091347

On macOS 27.0 beta (26A5388g), MacBook Pro M4 Pro, the built-in ProMotion display never settles on a stable refresh cadence. Scrolling in SwiftUI judders constantly. The same app binary was smooth on macOS 26, and is smooth on a 120 Hz ProMotion iPad.

I captured two 60-second Instruments traces — same app, same scene, same scrolling, no external display — changing only the display's refresh-rate setting. On ProMotion the vsync interval standard deviation is 4.093 ms across six different cadences, mostly flip-flopping between 120 Hz and 60 Hz. Forced to a fixed 60 Hz it drops to 0.391 ms with a single cadence. The app presented an identical 59 fps median in both runs — frame production is perfectly steady, the display just holds each frame for an unpredictable length of time.

That's what makes this nasty: it's invisible to every frame-rate metric, so it looks like the app got slow when nothing about the app changed. I spent most of a day profiling my own code before realising the app was never the problem.

Workaround: force the built-in display to 60 Hz.

Worth noting, because it complicates the picture: attaching a 60 Hz Studio Display makes the built-in smooth, but the Studio itself then judders — despite its own vsync cadence measuring perfectly stable. So refresh rate alone isn't the whole story, and there may be a second mechanism. The clean, reproducible, single-variable result is the ProMotion vs forced-60 Hz comparison on the built-in panel.

If you can reproduce this on an M-series MacBook Pro on 27 beta, please file a duplicate referencing FB24091347.

Answered by DTS Engineer in 902186022

Hello @arthurfromberlin,

Thank you for the update.

I have made sure your report has been seen by the relevant engineering team. Since a resolution for this issue might require changes to the framework or OS you are using, updates will be provided to you through Feedback Assistant.

Use this thread to share updates against versions as they are released, or share a workaround if you come across one. You can also share this information with the relevant engineering team directly by replying in Feedback Assistant.

For more details on Feedback Status, please see Understanding the Status of Your Feedback

Thank you,

 Travis

Answer 1

arthurfromberlin OP

3d

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.

Answer 2

DTS Engineer OP

Apple

3d

Recommended

Hello @arthurfromberlin,

Thank you for the update.

I have made sure your report has been seen by the relevant engineering team. Since a resolution for this issue might require changes to the framework or OS you are using, updates will be provided to you through Feedback Assistant.

Use this thread to share updates against versions as they are released, or share a workaround if you come across one. You can also share this information with the relevant engineering team directly by replying in Feedback Assistant.

For more details on Feedback Status, please see Understanding the Status of Your Feedback

Thank you,

 Travis

Answer 3

DTS Engineer OP

Apple

3d

To help with our investigation can you share the sample project you mentioned in your report.

Reproduced with a Mac Catalyst app embedding a RealityKit ARView alongside SwiftUI ScrollViews.

Attach this in your report or here in this thread. Incude explicit steps to reproduce the issue.

Thanks again.

 Travis

Answer 4

arthurfromberlin OP

2d

@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!