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 is 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 or LLVM.

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

In the previous video, you learned what a breakpoint is and what types of breakpoints Xcode supports. In this video, we step through code using a breakpoint and the debug bar we explored earlier in this course.

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

Earlier in this course, we briefly explored the types of breakpoints you can use in Xcode. In the previous video, we focused on file and line breakpoints. This video 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.

In the previous video, we used the Swift error breakpoint to suspend the process of the app if an error is thrown in your code or the code of a library or framework. The exception breakpoint works in a similar way. The difference, as you may have guessed, is that the debugger suspends the process of the app if an exception is thrown.

A few years ago, Apple added support for detecting potential issues at runtime. Runtime issues show up as purple issues in Xcode's Issues Navigator. They are easy to miss or ignore, but they are just as important as errors at compile time.