Forgotten Xcode Debugger Tricks

If you’re a pro iOS programmer, you may be a master at using the debugger. I, however, am not quite there yet.

I recently realized I’m very inefficient at debugging. So I decided to revisit Paul Hegarty’s lecture on the debugging. I’m glad I did because I relearned a couple tricks I had forgotten about debugging in Xcode.

Trick #1 – Immediately Break On All Thrown Exceptions

Instead of having all your uncaught exceptions get tossed up the stack to main, tell the debugger to break once they are thrown. This will help you debug your code much faster since you will know right where the exceptions are thrown in your code. To set this up, do the following:

  1. Go to the Breakpoint navigator in Navigators pane on the left (Cmd + 6)
  2. Click the little plus sign (+) button at the very bottom left
  3. Select “Add Exception Breakpoint…”
  4. Keep the defaults and click “Done”.
Xcode Debugger Break On All Exceptions

Trick #2 – Conditional Breakpoints

This is awesome for those methods that get called over and over again and you want to set a breakpoint to check the value of some variable (e.g. make sure it’s not equal to 0 or nil) but you don’t want your app to break…every…single…time. To enable conditional breakpoints follow these steps:

  1. Set a breakpoint
  2. Right click (or two finger tap) over the breakpoint
  3. Select “Edit breakpoint”
  4. Enter in a value (e.g. result == 0)
Xcode Debugger Conditional Breakpoint

Trick #3 – Access Variables Using the Debugger CLI

Sometimes it’s nice to see the value of a variable without hovering over it. From the debugger console, you can type something like print [self myVariable] to see the value of myVariable. However, this only shows the most information, like the value of the pointer (which if it’s 0x0 then it’s nil).

Another alternative is to do something like po [self myVariable], which basically calls the description method on the the object so it will print it’s description (“po” stands for “print object”). If myVariable is an array, you will see the contents of the array. This becomes quite useful if you get into the habit of coding description methods for your classes because then you can enter po self in the debugger and get all the information you need on the current instance of your class.

Conclusion

As you can imagine, there are a lot of other useful things you can do with simple modifications of these three tricks (i.e. adding actions to tricks 1 & 2, ignoring breaks on trick 2, exploring the other commands that can be used in the debugger CLI, etc.).

Lesson learned: Don’t be inefficient with your debugging. Explore the available tools.

Comments, questions and feedback welcome.