I have Xcode 15 installed in Sonoma on a mid 2014 MBP 15" (not officially supported hardware — uses OCLP). There is a big issue with rendering Storyboards, which corrupts not just the rendering of Xcode, but all visible desktops and workspaces as well. They are not workable.

Broken storyboard rendering

There are no crashes, and rendering can be restored to normal simply by hiding the Storyboard editor and making sure all corrupt areas are re-rendered, which suggests the issue is simply with rendering instructions and isolated to graphics buffers.

This only happens when external monitors are connected.

  • Did you file feedback with Apple? A sysdiagnose should help them fix this spectacularly failed rendering situation.
    – bmike
    Commented Jul 3 at 12:24
  • @bmike It's hardware that is no longer officially supported by the OS, which is why OCLP is needed. I'll add that to the Q
    – Andreas
    Commented Jul 3 at 12:49
  • Yes - Apple will see that report as a total waste of time. Definitely let the OCLP people know with a bug report and link here…
    – bmike
    Commented Jul 3 at 13:08

1 Answer 1


I've learned that the issue only occurs if the storyboard is opened while there is an external monitor connected, and I've also learned that external monitors are handled by the discrete GPU on this machine.

From this, combined with OpenCore Legacy Patcher's note about how Storyboard rendering can become corrupt on Kepler graphics, and combined with that the issue is not present on Macbooks that only have Intel integrated graphics, I conclude that this is only an issue when Xcode uses the discrete GPU for rendering work. Unfortunately, the discrete GPU's involvment is required since I want to use an external monitor.

The next discovery was that Storyboards not only worked fine as long as I opened them while no external monitor was connected, but also continued working after I plugged it back in. Clearly the render surfaces acquired and retained some sort of affinity for one of the two GPUs at creation time.

I thought about it some more, because I don't want to constantly unplug monitors, and asked myself if there isn't another system state that will also force apps to use the integrated GPU instead of the discrete one. What about power saving?

After unplugging the power cable and launching Xcode/opening storyboards on an external monitor, on battery power, I indeed get the same result as when no monitor is plugged in. This is much better than unplugging and plugging two monitors back in every time.

In conclusion: if you can accept working around this problem on an individual basis, you can force Xcode's storyboards to prefer the iGPU during their lifetimes simply by unplugging the charger before opening them. I imagine you'd need to enable the system's power saving setting to dynamically switch GPUs for this to work.

If you could somehow programmatically force the system into its power saving state, or to always pick the integrated GPU some other way, then I suppose that you could theoretically automate this.

  • Those dual-GPU Macs barely worked with Apple's supported drivers, and the hardware was prone to failure too. There are methods of setting which GPU gets used, ISTR, with Terminal commands.
    – benwiggy
    Commented Jul 3 at 14:00
  • @benwiggy Interesting. I got it recently so I don't have any experience with how they performed with OS support, but so far I'm not impressed — the rubber screen gasket has partially melted from excessive heat and the speakers sound as if they suffered the exact same fate. The anti-reflective coating as well, which came off with alcohol. If there are ways to assign apps to a GPU that'd be great, if you remember. There's an unanswered Q on here about that. There's codyschrank.github.io/gSwitch but not applicable here since it can't be used with external monitors.
    – Andreas
    Commented Jul 3 at 15:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .