3 Essential Debugging Tools in Xcode
Xcode is a powerful IDE and it provides a wide variety of debugging tools. While many of these tools are straightforward to discover and use, I’ve noticed that many iOS developers do not know about the existence of the slightly more advanced (but essential) debugging features, hidden in Xcode. I’ve decided to build up this short list of debugging tips for Xcode, which represents the instruments I use to debug my code, in most cases. I’m sharing them in the hope that your productivity will increase after discovering these hidden gems.
1. View Hierarchy Debugger
I was surprised to see a few experienced iOS engineers who didn’t know about the existence of this feature. It’s common to debug the view hierarchy by programmatically changing the background colors of all the views laid out on the screen in order to observe what’s going on. You’d think this is very inefficient, if you knew about the “Debug View Hierarchy” button, which is hidden in plain sight in the Debug Area bar (next to the Resume/Pause debugging buttons).
This feature allows you to investigate the relationships of view objects, in a 3D rendering, called the view hierarchy debugger. You get a nice visualization of the layout tree, where you can notice immediately whether something is wrong with your UI.
Give this feature a try, before setting up paid tools, such as Reveal App. The Xcode built-in view hierarchy debugger is quite powerful and it’s usually all the tools you need to debug view hierarchy.
While working on a generic collection view controller, which I created for iOS App Templates, this tool was amazing in debugging a fluid layout class, which allows the collection view cells to have flexible (unequal) widths and heights.
One extra tip — I like to use this tool to find out where the code for a specific screen/component lives, since you can identify the name of the classes that are backing up the user interface easily. Very convenient in unfamiliar codebases.
2. Rich Breakpoints
If you’re fairly new to iOS, you probably only used simple breakpoints, to break into any method you’d like, during debugging, to observe what’s the current runtime context (variables, states, object relationships, etc). You can set up a breakpoint by simply clicking on the lefthand side bar on a specific line of code and Xcode will pause the execution of the program whenever that line is being run.
What many iOS developers don’t know is that breakpoints can be even smarter than this regular use case. In fact, they are quite impressive. Here are a few helpful tricks you can do with them:
- Conditional breakpoints — the breakpoint gets hit only if a given condition is true. This is very helpful for debugging lists (for example), where you only care about what’s going on in the N-th cell and want to skip pausing the execution on each previous list item.
- Ignore — You can ignore pausing on the breakpoint for a fixed number of times. This comes in handy in many situations, including the one described above.
- Action breakpoints — you can tell Xcode to perform a specific action when the breakpoint is being hit. The actions can be logging a message, running a debugger command (such as “po”), or even running a shell script. A very interesting feature here is playing a sound whenever the breakpoint activates. This saves a lot of debugging time when dealing with breakpoints in methods that are called very often (such as layoutSubviews).
To play around with all of these features, you can right-click on the breakpoint and choose “Edit breakpoint”.
3. Exception breakpoint
When debugging exceptions, this is a life savior. Instead of manually tracing down the code causing the exception, you can just add this generic Xcode breakpoint, which will pause the execution right before the exception is thrown. In this way, you can investigate what’s the exact context when the exception is thrown, which will almost always show exactly what the bug is, in a matter of seconds. Very helpful when debugging unfamiliar code.
To set up this breakpoint, go to the breakpoint navigator (Command + 8), click on the “+” sign at the bottom and choose “Exception Breakpoint”. You can also edit this breakpoint to make it even richer, since it supports all the features outlined in the previous section.
In the same menu, you can find a broader set of generic breakpoints, such as test failure breakpoint (which pauses the execution right before the test fails), swift error breakpoint, symbolic breakpoint, etc. We’ll leave them as an exercise for the reader, since they’re not very often used (not by me, at least).
I hope this is useful and you learned something new by reading this article. Please feel free to share any additional tips in the comment. I’m looking forward to learn what other Xcode debugging tools people find convenient and effective.
Check out more tips & tricks for debugging iOS code in Xcode!
