Nope, iPhone 11 devices are still stuck on start. @Ash_Bash 's workaround working; but I am not sure if I should go with that solution. Still, I want to update our Unity version because of this. I am stuck like an old iPhone too. There are several other important bugs to report and I have no enough time to report them. -_-
Thanks for the pointers on this ![]()
I implemented [PostProcessBuild] into the build pipeline (with logging) and UNITY_USES_METAL_DISPLAY_LINK is now disabled in builds.
Whilst I never experienced the issue on the handful of test devices Iâve tried, I canât see any harm in this and it doesnât appear to have affected performance.
FWIW⌠I also added some extra defensive coding to check that the original define is present before attempting the change. If itâs not, the build fails. This way if\when Unity changes this in the future Iâll hopefully know about it and can adjust accordingly.
I see that 6000.0.60f1 has been released.
The changelog reports a similar issue being fixedâŚ
Not sure if itâs the one reported above, so this is just an FYI.
Hmmm⌠It is not fixed.
Thank you⌠I guess Iâll wait another couple of weeks.
Tested on 6000.0.59f2 and 6000.0.60f1, itâs still not fixed, same like what others reported. Is this being prioritized? Since the similar bug report was also closed, should we create a new bug report for this?
To be more specific, the game started freezing for few seconds when minimizing it to home screen or switching to other apps. Then going back to the game will result in freezing + flickering. Interestingly, the freezing doesnât always happen, but just randomly. I had to restart the game and swipe up to minimize the game and go to homescreen for around 8-10 times in order to trigger the freezing. Itâs almost 100% happen for first time game launch after a fresh install.
The device console log showed this warning:
Execution of the command buffer was aborted due to an error during execution. Caused GPU Timeout Error (00000002:kIOGPUCommandBufferCallbackErrorTimeout)
Tested on 6000.0.59f2 and 6000.0.60f1, itâs still not fixed, same like what others reported. Is this being prioritized?
all the issues we have found (read: all the bugs that were reproducible on our end) in regards to metal displaylink were fixed in .60 (or earlier). It will be prioritized the moment we got smth that can be reproduced
Since the similar bug report was also closed, should we create a new bug report for this?
which bug are you talking about?
the game started freezing for few seconds when minimizing it to home screen or switching to other apps.
that sounds totally bad but iâve never seen it. Or rather whenever i saw anything like this - it should be fixed in 6000.0.60
Not really @Alexey
We use Unity as a Library and can share more informations about those issues.
[iPhone XR / iOS 17.6.1] => Unity 6000.0.60f1
- CADisplayMetalLink enabled => In background no issue, but displaying Unity in front hang indefinitely
- CADisplayMetalLink disabled => It works well
[iPhone 16 / iOS 26.0] => Unity 6000.0.60f1
- CADisplayMetalLink enabled => it works well
- CADisplayMetalLink disabled => we have some drop of Framerate from 60 to 40 average when putting the app in background and opening again
And we didnât find a way yet to make it work for both.
The problem is that we managed to make multiple setups work with different Unity version and it seems to be only related with the CADisplayMetalLink switching or not to basic CADisplayLink.
This is related to the update in Unity 6000.0.56 and specifically specifically :
OS: Added support for CAMetalDisplayLink. It is enabled by default on ios (when built with xcode15+ and run ios17+). It can be overriden at runtime by tweaking/overriding [UnityAppController shouldUseMetalDisplayLink] method. By default it is disabled on tvos, since most of them are slow, and failing to catch up with target FPS (on complex scenes) will result in confusing GPU hang messages.
yes - bug report with repro project (the âsmallerâ/easier you can make it the better - but we will survive with anything, even xcode project is totally fine for this issue)
CADisplayMetalLink enabled => In background no issue, but displaying Unity in front hang indefinitely
again, see above - we need something that can be run, showing the issue (even if inconsistently)
CADisplayMetalLink disabled => we have some drop of Framerate from 60 to 40 average when putting the app in background and opening again
hm, iâve heard there was a bug in ios26 itself with CADisplayLink, but also .60 had one fix specifically about us doing bad things with CADisplayLink
EDIT: as i understand, in your case everything will work if you do smth like
- (BOOL)shouldUseMetalDisplayLink
{
#if UNITY_USES_METAL_DISPLAY_LINK
if (@available(iOS 26.0, tvOS 26.0, *))
return YES;
#endif
return NO;
}
@Alexey Your solution seems to work ![]()
By doing additional tests on our side it seems this issue is related to iOS 17 specifically.
We have no issue on iOS 16.7.12 and iOS 18.6.2 with any recent Unity 6000 (even with 6000.0.60f1)
On the documentation Apple confirm they âsupportâ iOS 17+ but Iâm not sure itâs well supported on this specifically iOS 17 version.
Checked the Xcode project generated by Unity and it is compliant with Apple minimum versions.
We did a BuildPostProcess patch based on your proposition and it seemed to work on our test devices.
But I have the feeling itâs like a ticking bomb and would be great if managed by Unity in upcoming version at some point.
Here is the snippet if it can helps anyone :
[PostProcessBuild]
private static void OnPostprocessBuild(BuildTarget buildTarget, string path)
{
#if UNITY_IOS
PatchUnityUsesMetalDisplayLink(path);
#endif
}
private static void PatchUnityUsesMetalDisplayLink(string pathToBuiltProject)
{
string[] mmFiles =
{
Path.Combine(pathToBuiltProject, "Classes/UnityAppController.mm"),
Path.Combine(pathToBuiltProject, "Classes/UnityAppController.h"),
Path.Combine(pathToBuiltProject, "Classes/UnityAppController+Rendering.mm"),
Path.Combine(pathToBuiltProject, "Classes/UnityAppController+Rendering.h"),
};
foreach (var mmPath in mmFiles)
{
if (!File.Exists(mmPath))
{
UnityEngine.Debug.LogWarning($"File not found: {mmPath}");
continue;
}
var original = File.ReadAllText(mmPath);
var patched = PatchInsideMetalBlocks(original, Path.GetFileName(mmPath));
if (patched != original)
{
File.WriteAllText(mmPath, patched);
UnityEngine.Debug.Log($"Replaced '17.0' â '26.0' inside UNITY_USES_METAL_DISPLAY_LINK blocks in {Path.GetFileName(mmPath)}");
}
else
{
UnityEngine.Debug.LogWarning($"No changes made in {Path.GetFileName(mmPath)} (no matching blocks or already updated).");
}
}
}
all the issues we have found (read: all the bugs that were reproducible on our end) in regards to metal displaylink were fixed in .60 (or earlier). It will be prioritized the moment we got smth that can be reproduced
Tested on 60f1 and the issue still persists using iPhone 12 with iOS 26.0.1. No issue on iPhone 16 Pro.
which bug are you talking about?
https://issuetracker.unity3d.com/issues/ios-the-player-freezes-and-execution-of-the-command-buffer-was-aborted-due-to-an-error-during-execution-dot-error-is-continuously-logged. I was having the similar error in iOS console log when the freeze happened, though this issue maybe slightly different than my case.
that sounds totally bad but iâve never seen it. Or rather whenever i saw anything like this - it should be fixed in 6000.0.60
It happens randomly. I gotta restart the app for about 8-10 times to get it repro the issue. Sometimes the freezing just shows up for first time install. Itâs slight hard to repro, but we got it consistenly after a few app restarts.
Hi!
This issue is different as the error we get is: kIOGPUCommandBufferCallbackErrorPageFault. This was caused by accessing out-of-bounds memory in the Clustering.hlsl in the Universal Render Pipeline (URP). We have fixed the shader already in the latest versions of Unity 6.X.
Now for the hang/freeze that this thread is about, we get a different error:
kIOGPUCommandBufferCallbackErrorTimeout. This means that there is a command buffer that took too long to complete and the system decided to terminate it. Once this happens, all subsequent command buffers are ignored by the Metal driver, effectively causing a permanent freeze of the rendering. Itâs strange that CAMetalDisplayLink is causing such an error but we are investigating the issue.
If you have any Unity or XCode projects that have this issue, we would be very interested in testing those to help us fix this issue.
Thank you!
@joao_maia_u3d
I have similar issue about GPU timeout error on iOS (especially, iPhone 17 Pro (iOS 26.0.1)).
After my app running 1 ~ 1.5 hours, it throws GPU timeout error and rendering is broken. I turned off my all of ScriptableRenererFeatures and disalbe all features of URP settings (color/depth texture, postprocessing, MSAA and so on), but it still freeze. My Unity version is 6000.2.6f1. Do you have any known issue ticket about this?
Related post: iOS app rendering is broken due to GPU timeout error
Hi @Kichang-Kim. Yes, we have similar issues we are currently investigating.
The only way to fix this at the moment is to disable the CAMetalDisplayLink.
In your XCode project, go to Classes/UnityAppController.mm. In this function shouldUseMetalDisplayLink change return YES; to return NO;.
@joao_maia_u3d After disabling MetalDisplayLink, freezing issue is gone maybe. Iâll test with more various devices and time. ![]()
Hi @PeachyPixels.
The release notes are indeed incorrect. We will update the release notes to show the correct issue.
UUM-111494 is a different issue in the sense that the GPU error was caused by an out-of-bounds access in a Universal Render Pipeline (URP) shader. This has been fixed in 6000.0.56f1.
However, in 6000.0.56f1 we also got another change:
iOS: Added support for CAMetalDisplayLink. It is enabled by default on ios (when built with xcode15+ and run ios17+). It can be overriden at runtime by tweaking/overriding [UnityAppController shouldUseMetalDisplayLink] method. By default it is disabled on tvos, since most of them are slow, and failing to catch up with target FPS (on complex scenes) will result in confusing GPU hang messages. (UUM-66493)
Unfortunately, CAMetalDisplayLink is causing Metal Timeout errors which also results in a GPU freeze. The game keeps running, but all GPU work stops.
For now, you need to disable this in [UnityAppController shouldUseMetalDisplayLink] in your XCode project in Classes/UnityAppController.mm.
In 6000.0.62f1 (not public yet), the CAMetalDisplayLink is disabled by default so you wonât need to make this edit.
This is being tracked in UUM-123207
Thanks @joao_maia_u3d
Thatâs definitely cleared things up.
Iâm reading that as two fixes made in 56f1 but one remaining to be fixed in 62f1
Iâm guessing the âfixâ is the disabling of CAMetalDisplayLink in 62f1 whilst the actual fix will come later?
The fix for now is to disable CAMetalDisplayLink. This needs to done by editing Classes/UnityAppController.mm in your XCode project for 6000.0.56f1, 6000.0.57f1, 6000.0.58f1, 6000.0.59f1, 6000.0.60f1 and 6000.0.61f1.
In 6000.0.62f1 the CAMetalDisplayLink is disabled by default, so you donât need to edit Classes/UnityAppController.mm.
We are still investigating and testing how we can use CAMetalDisplayLink without causing the Timeout error and cause freezes. A fix for this will come in a later version. Itâs possible that the CAMetalDisplayLink will continue to be disabled by default though until we are more confident about the stability.

