Reading Time: 5 minutes

A WWDC talk about debugging in XCode made me rethink some things, so I decided to write about it in three parts:

1. An outline of the techniques demonstrated in the talk
2. How the talk challenged my views both on XCode and on learning a new stack 
3. Additional XCode debugging features not covered in the talk (this post)

Thank you to the talk hosts, Chris Miles and Sebastian Fischer, for unwittingly enabling this tangent 😃.

Here‘s where Apple keeps the video of the talk:

At that link, you can also:

• Get a transcript of the talk
• Download an HD version of the video (the low-resolution version embedded on the site itself makes it hard to read the text in the IDE)
• The slides (They don’t use these in the presentation, opting instead for live demos, which I think is more clear. But, if you like, the slides are there).

Additional Debugging Features in XCode

Part I of this series outlines the XCode debugging features covered in the talk (especially Chris’s portion). I thought it would be fun to write an addendum about some features that the talk doesn’t cover, that I have used from time to time.

Thisaway, please…

Ways to inspect the runtime environment when paused at a breakpoint:

The talk shows how to set a breakpoint. When we hit a breakpoint, we can:

• Investigate the outline of the objects currently in memory
• evaluate (and print) expressions from the command line
• print information about objects in memory in concise and verbose formats

But I wanted to provide some more context on when and how you might use each of these options. So I made you a little video!

I find myself using printing extensively in many of my debugging pursuits, so I want to keep you well-equipped with all of the printing options!

What else can we do when paused at a breakpoint?

Suppose we don’t enable the option to auto-continue past a breakpoint, and we’re paused at one in the simulator. What can we do from here? A lot, actually:

These breakpoint navigation options in the XCode Debug menu allow you to step through your code’s execution, line by line. And you don’t even need the menu! You can use the handy key bindings listed to the right of each option on the menu.

I won’t go over all of the options in this menu, but here are some of the ones I find myself using the most:

• Continue: This is your “play on” option. Clicking this is the manual version of checking the “auto-continue” box on a breakpoint. Your code will keep executing at full velocity.
• Step Over: Evaluate the line where you’re currently paused and move down to the next line of code.
• Step Into: Are you currently paused at a function call? Step into that function! See what happens line by line in there!
• Step Out: Finish executing the function you are in and go back to the place where it was called from so you can continue executing line-by-line from there.
• Step Over/Into Thread: Move down the call stack, or into the call stack, on the particular thread your breakpoint is on while keeping the others paused. This differs from the “default” case, which runs everything.
• Step Over/Into Instruction: Move down the call stack by individual CPU instruction rather than by line of Swift code. This is definitely a pro level move and perhaps of special interest to you if you’re simultaneously learning about iOS and, say, compilers.

I also encourage you to experiment also with some of the other options in this menu. What do they do? Can you imagine a situation in which you might use them?

Inspecting the Memory Graph

In Part 1 of this series, we talked about the XCode feature for debugging the view hierarchy. There’s another button near the “Debug View Hierarchy” button to which I’d like to introduce you.

This button has the label “Debug Memory Graph,” and it shows you, from your simulator, the exact objects held in memory by the app at the time it is clicked. I demonstrate in this video (this link will take you to 1:53, where I start talking about this specific feature):

We can use this feature to debug our apps and gain greater insight into the allocation and deallocation of our objects.

In fact, in this video, you can see an example: I use the memory graph debugger on my favorite Angry Birds parody app to explain how object conservation works in mobile applications (this link will jump you right to the part where I talk about this).

Nifty, right?

I thought so. In particular, I was sad to discover that the JetBrains editors currently possess no equivalent (that I could find) of “Debug Memory Graph.” If you find one, I’ll send you cookies.

But in the meantime, I hope I have inspired your curiosity about your debugging tools in XCode, or whatever IDE you call home :).

If you liked this piece, you might also like:

The Raft series—if you seriously think debugging tools are interesting, you’ll love the absolute barking spider circus that is the Raft walkthrough.

The Leveling Up Series (a perpetual favorite for gearheads like yourself)

The Books Category, to which I’m slowly adding all the blog posts where I reflected on a book