At that point you should just turn on your IDE’s time travel debugging configuration or at the very least its full execution trace configuration. No point fumbling around trying to figure out what happened if you are rebuilding anyways.
good ol’ print statements are still the best tools for the job
Apart from breakpoints debuggers (just not lldb if I'm not mistaken) can also support 'tracepoints' i.e. register a certain code location for having a custom string being printed. Can be better and more convenient than print statetemnts especially because it doesn't change the program. Also great when you have bugs which disappear after adding print statements.
Re:A few useful Xcode debugging tricks
by victorthehuman on Tuesday August 17, 2021 @07:15AM
(#28208608)
The problem with those types of breakpoints is that they slow down the app considerably.
Put one of those in a tight loop and the timing related bug you're after could be gone.
Only if they are implemented inefficiently or your application is constrained in a way that precludes efficient implementation.
As long as you can inject code and steal some memory you can just directly patch in the code snippet and patch in a branch instead of a breakpoint instruction. This is functionally equivalent to a adding a print statement, just at runtime instead of compile time, so should not be significantly slower.
For tracking gesture and scrolling events, though, breakpoint debugging is outright impossible to work with, and good ol’ print statements are still the best tools for the job.