I’m already disabling CAMetalDisplayLink (by modifying UnityAppController.h) so all good in that respect. I was just trying to get an understanding on where Unity is with these issues.
To be honest, disabling it has had no noticeable impact on game performance, but I’ll keep an eye out for any updates and maybe it’ll be enabled in the future (if it’s reliable enough)
Thanks again and good luck with the investigating
PS: Might Unity consider adding this a configurable project setting rather than buried away, where it’s harder to find\change?
There was an old framedrop problem with the ProMotion iPhones (not with iPads interestingly, not sure about the newer models) and it was probably an iOS bug (Unity thread, Unity bug report), because even the web browser and cocos2d has similar problems. I think this is resolved in iOS 18.4 or in some version; because we’re not seeing that problem anymore. The problem was, if you’re on a ProMotion iPhone, even if you’re running the game at 30 FPS, the framerate will drop to half (in this case 15 FPS) whenever you touch to screen. There were some “workarounds” but these were randomly working or not working. I think Apple’s implementation for VRR or high refreshrate (or similar things) a bit different/complex. It’s been 4 years since the iPhone 13 Pro is released, and we still have problem with ProMotion iPhone displays
The issue with the “patch” to disable CAMetalDisplayLink is that it will fix the hang but will bring back the frame rate drop on most of devices on iOS26.
This fix to enable CAMetalDisplayLink in the 6000.0.56f1 version was to fix this particular issue of drop of frame rate.
You manage it in a ping pong way between enabling and disabling the CAMetalDisplayLink.
But anyway whatever the option you chose, one of those issue will pop :
Disable CAMetalDisplayLink => Frame rate drop on iOS26
Enable CAMetalDisplayLink => Hang on older iOS versions
It seems we are trap into choosing which bug we prefer
Reading your posts (and the links) I would say I’d take the FPS drop over a hang any day of the week.
I’ve been compatibility testing my app (on a device farm) across dozens of different device\os versions (with CAMetalDisplayLink disabled) and so far no issues to report
Of course there are thousands of combinations, so guess it’s still a small snapshot of what’s actually out there.
So I just built a new version (in UBA) with 6000.0.62f1 but I’m still seeing the define that determines if CAMetalDisplayLink is enabled and it’s the same as it was in 61f1 (and earlier)
In the Xcode console you should not see CAMetalDisplayLink created and instead you should see CADisplayLink created.
We disabled the CAMetalDisplayLink in a different way. Check - (BOOL)shouldUseMetalDisplayLink in UnityAppController.mm and you should see that all code paths return NO.
