My pain points are mostly in the CPU debugger (since I'm not using much of the actual "IDE features" of Xcode except the regular edit-compile-debug loop anyway.

Starting a 'cold' debug session into a UI application may take 10-ish seconds until applicationDidFinishLaunching is reached, and most of that time seems to be spent with loading the symbols for hundreds of framework DLLs which are loaded during application start (which I never even need because I can't step into system frameworks anyway) - and seriously, why are there even hundreds of system DLLs in a more or less hello-world-style Metal application with minimal UI? This problem seems to go back to the ancient times, but it gets worse and worse the bloatier macOS UI processes become (e.g. the more system frameworks they load at start).

The debugger variable view panel is so bare bones that it looks like it's ripped out straight from an 80's home computer monitor program.

When debug-stepping, the debugger frontend is quite often stuck for 10s of seconds at completely unpredictable places waiting for the debugger to respond (it feels like a timeout).

Step-debugging in general feels sluggish even compared to VSCode with lldb.

For comparison, VS2026 isn't exactly a lightweight IDE either, but debugging sessions start instantly, debug-stepping is immediate, and the CPU debugger is much more feature rich than Xcode's. While in Xcode, everything feels like it's been added as a checklist item, but then never actually used by the Xcode team (I do wonder what they're using to develop Xcode, I doubt that they are dogfooding their own work).

The one good and useful thing about Xcode is the Metal debugger though.

Yes, I develop C++ on XCode and Visual Studio. I've recently started using XCode more because the performance on my Windows tower has become abominable in the past couple years and the M1 laptop is still snappy.

XCode is just terrible compared to Visual Studio.

As you said, there are weird beachballs all the time both while stepping and while waiting for the application to stop at a breakpoint (in cases where it happens instantly running under VS on Windows).

The Jump to Definition seems to have gotten flakier. Or maybe it's always been terrible relative to Visual Studio, IDK. But regardless a lot of times I'm just going by memory and Cmd+F on XCode - Jump to Definition and Cmd+Shift+o are just not getting there.

The Variables pane in the Debugger often just fails to actually ... display anything for any of the variables when stopped at a breakpoint. Sometimes it will appear after stepping a couple lines, sometimes it won't.

The Debugger is even flakier than usual when Lambdas are involved.

I am an emacs guy so it's not like I'm disposed to like Visual Studio. Visual Studio's quality has slipped a little too. But XCode feels straight-up amateurish in comparison to it. That said, at least Apple is actually exposing the capabilities of the IDE to their LLM integration offering. This is an improvement over the abortion that is Copilot integration in Visual Studio.

Historically one of the big problems with Xcode has been that they only dogfood. There’s people on the team that have not touched any other IDE in decades. They’ve gotten used to all of the quirks, and just don’t really know that things could be better. Every new improvement has to be designed from scratch rather than just ripping off what other IDEs do better.

Apple internally has structured their projects to not run into all of the debugger performance cliffs, but don’t provide any guidance on how to do the same thing and don’t proactively fix the problems they’ve avoided.

Every time I’ve talked to someone who has worked on Xcode they’ve expressed the opinion that Xcode is best-in-class and they simply don’t understand why people disagree.

> Starting a 'cold' debug session into a UI application may take 10-ish seconds until applicationDidFinishLaunching is reached, and most of that time seems to be spent with loading the symbols for hundreds of framework DLLs which are loaded during application start (which I never even need because I can't step into system frameworks anyway) - and seriously, why are there even hundreds of system DLLs in a more or less hello-world-style Metal application with minimal UI?

This is so you can see function names for system frameworks. You can step into them if you want too even if Xcode tries to stop you doing it by default.