Xcode 26.6 Frequently Freezes During Breakpoint Debugging with Simulator

Question

Created 1d

Replies 4

Boosts 0

Participants 2

When I use Xcode 26.6, MacOS Tahoe 26.6.2, for debugging and hit a breakpoint, using "step over" very often causes the debugger to freeze at a random line of code on other threads.

Clicking "Pause program execution" indicates that the line is being executed randomly on other threads, but the breakpoint never exits, seemingly causing a freeze.

At this point, if I then place a breakpoint just after the point where I was stepping on the thread which I was debugging before the freeze, hitting "Continue Program Execution", ofter - but not always - the debugger returns to the new breakpoint which I placed after the freeze.

I am using Xcode on Apple Silicon M4 based Mac, our app is a ObjC application for MacOS and it is native for Apple Silicon.

The current situation with Xcode 26.6 significantly reduces our development efficiency. What could be causing this, and is there a solution?

Answer 1

sdaino OP

1d

NOTE: Unlike what is stated in the title, I do not use any simulator, as the application is native to MacOS.

Answer 2

Etresoft OP

1d

Debugging has been borderline unusable for a couple of years. It's not unusual for a delay of a 30-60 seconds when first hitting a breakpoint. You have to wait until the spinner disappears and your variables show up. Otherwise you'll lock it up.

A much better strategy is printing out debugging messages. For a typical multithreaded, asynchronous app, standard breakpoints aren't practical at all. Debug messages are the only way to go.

And they can even serve double-duty. Sometimes you do need the debugger. A debug print statement can be a convenient place to set your breakpoint as it won't involve any real logic.

PS: Make sure to roll your own debugging system. Apple's built-in logger is awful. You have to do extra work to avoid making all of your debug data <private>.

Answer 3

sdaino OP

19h

I understand, however I'm working on a digital audio application, and the audio thread is called very 12 msecs. When I'm so desperate to use debugging messages on the console, the printing queue collapses after a few seconds...

We really need a solution. It always worked in the past. Hopefully Apple did not start using Claude writing new releases of XCode...

Answer 4

sdaino OP

11h

ADDITIONAL NOTE:

Hoping this helps the DTS team find the problem, it seems there's something to do with where the application window is located relative to the XCode window.

It appears that if the application window isn't below the XCode window, the debugger unfreezes after a freeze. It's as if XCode's event loop is affected by the overlap between the XCode window and the application window.