Chapter 6
Debugging Code

It feels great when your code builds without errors, but sometimes that means your work is just getting started. Even if your app runs, chances are it has bugs: logic that does the wrong thing when it’s actually run, UI elements that don’t look right, or worst of all, a full-blown crash of your app.

When you have bugs, it’s time to start debugging.

But… how? If you wrote the code wrong the first time, how do you figure out how to make it right? Is program execution not reaching some important part of the code, or is it making bad decisions once it does? Many developers will hop into the troubled part of the code and add logging statements (print in Swift, NSLog in Objective-C, or printf in C) to get some idea in the Xcode console of what’s going on. This inevitably takes multiple build-and-run cycles as you narrow down what you even need to log, figure out what the problem is, fix it, and then clean up all the logging statements.

This process can be a lot more elegant and productive than that. Xcode has deep and powerful debugging features, courtesy of the Low Level Debugger. lldb, as we’ll call it from here on out, gives you powerful abilities to inspect the program flow and state of your app, catch your app in mid-crash, and even let you change program state at runtime. Once you know lldb, you may never want to use logging statements for debugging again (which means you can leave them to their true purpose: logging problems experienced by users in the field).

This chapter focuses on logic, appearance, and crashing bugs. Once those are dealt with, the next chapter will move on to finding and fixing performance bugs.