Everyone makes mistakes and developers are no different. As a developer, you spend a significant portion of your time debugging the code you write. It's an inextricable aspect of software development. Some bugs are easy to find while others can make you scratch your head.

Xcode offers developers a mature development environment with a powerful debugger. Under the hood, Xcode's debugging tools take advantage of LLDB, the debugger of the LLVM project. It isn't necessary to have a deep understanding of LLDB or LLVM to make use of Xcode's debugging tools, but it certainly doesn't hurt to become familiar with LLDB and LLVM.

Breakpoints are indispensable for debugging problems in a software project. Debugging an application with breakpoints can appear complex at first, but it isn't difficult once you understand what's going on. While the underlying concept of debugging with breakpoints is simple, you can make it as complex as you want.

When you're debugging a complex problem, you quickly end up with dozens of breakpoints scattered across your project or workspace. I'd like to start this episode by showing you how you can stay on top of the breakpoints in a project or workspace.

Earlier in this series, I briefly listed the types of breakpoints you can use in Xcode. In the previous episode, we focused on file and line breakpoints. This episode zooms in on symbolic breakpoints.

Error handling is a key aspect of the Swift language. In several ways errors in Swift are similar to exceptions in Objective-C and C++. Both errors and exceptions indicate that something didn't go as planned. The Swift error and exception breakpoints are useful to debug scenarios in which errors or exceptions are thrown.

The test failure and constraint error breakpoints are lesser known breakpoint types. When used correctly, however, they can be quite useful. Let's start with the test failure breakpoint.

The past episodes of this series have illustrated how useful breakpoints can be for debugging problems. But Xcode has more in store for us. Not every problem can or should be debugged with breakpoints. Issues related to the user interface of your application are often best tackled with Xcode's built-in view debugger. In this episode, we explore the view debugger built into Xcode.

In the previous episode, we explored Xcode's built-in view debugger and you learned how the view debugger can help debug problems related to the user interface. Remember from the previous episode that I introduced several user interface issues in Cloudy. Let's find out how we can leverage the view debugger to discover and resolve these issues.

Xcode's built-in view debugger highlights some of the advantages visual debugging has to offer. I hope that the previous episodes have illustrated that debugging user interface issues is more efficient with Xcode's view debugger.

The memory graph debugger built into Xcode is a very welcome addition for debugging memory issues. In the previous episode, we resolved a memory issue we discovered somewhat by accident. While it can be useful to use the memory graph debugger to investigate complex object graphs, it would be convenient if Xcode warns us about possible memory issues. And that's exactly what the memory graph debugger does.