4 ms·

A few useful Xcode debugging tricks

29 points by ktustanowski 5y ago

3grdlurker 5y ago
I love this technique, but it can be very slow for large apps that have a less-than-ideal state of code cleanliness or architecture-and I assume that most apps fall under that category. 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.
- stinos 5y ago
  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.
  - victorthehuman 5y ago
    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.
    - Veserv 5y ago
      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.
- Veserv 5y ago
  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.
ElFitz 5y ago
My biggest issue with Xcode breakpoints, especially with the conditional "Automatically continue after evaluating actions" ones, is how much they can slow down the app.
pixel_tracing 5y ago
I thought this would be for analyzing assembly with LLDB in Xcode :( left disappointed. Most of these are well known to advanced iOS engineers.

29 points by ktustanowski 5y ago

I love this technique, but it can be very slow for large apps that have a less-than-ideal state of code cleanliness or architecture-and I assume that most apps fall under that category. 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.

stinos 5y ago
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.
- victorthehuman 5y ago
  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.
  - Veserv 5y ago
    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.
Veserv 5y ago
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.

ElFitz 5y ago

My biggest issue with Xcode breakpoints, especially with the conditional "Automatically continue after evaluating actions" ones, is how much they can slow down the app.

pixel_tracing 5y ago

I thought this would be for analyzing assembly with LLDB in Xcode :( left disappointed. Most of these are well known to advanced iOS engineers.