Xcode Breakpoints: How to Debug Faster with Breakpoints in Xcode

Breakpoints are useful for all kinds of debugging. But for iOS debugging, they’re critical.

iOS often veers away from the typical top-to-bottom flow. At the same time, its heavy reliance on async/await can inadvertently lead to concurrency and race conditions.

As devs, we need a way to stop the train before it goes too far in the wrong direction. This is what Xcode breakpoints are designed for.

In this guide, you’ll learn how Xcode breakpoints work and how to use them effectively while debugging. Specifically, we’ll cover:

• what Xcode breakpoints are
• how breakpoints in Xcode work
• how to create your first breakpoint
• how to step through code while debugging
• advanced breakpoint types available in Xcode
• practical tips for debugging iOS apps faster

Here’s the full guide. Feel free to skip anywhere you want.

What are Xcode breakpoints?

Xcode breakpoints are markers placed in your code that pause program execution so developers can inspect variables and analyze application behavior during debugging.

When the app reaches a breakpoint, Xcode stops execution and opens the debugger, allowing you to inspect:

• variable values
• object states
• memory references
• execution flow

This helps developers analyze the current state of the program and identify unexpected behavior more quickly.

How to use breakpoints in Xcode

The effective use of breakpoints really comes down to two things: how to set them, and how to get rid of them.

How to add breakpoints in Xcode

Creating a breakpoint in Xcode takes only a few seconds.

1. Open your project in Xcode and the Swift or Objective-C file you want to debug.
2. Click in the left gutter next to the line number. A blue indicator appears showing that a breakpoint has been added.
3. Press Run (▶).

When execution reaches the breakpoint:

• the app pauses
• the debugger opens
• variable values become visible

That’s it. Seriously.

How to disable or remove breakpoints in Xcode

During debugging, you may want to temporarily stop a breakpoint from triggering without losing its location in the code. This is useful when focusing on a specific part of the program without interruptions.

In other cases, once a bug is fixed, it’s better to remove the breakpoint entirely to keep the project clean.

To disable a breakpoint

• Click the breakpoint icon in the gutter to toggle it off. The icon becomes dimmed, indicating it is disabled but still saved in the code.
• Right-click the breakpoint and choose Disable Breakpoint or Disable All Other Breakpoints to focus debugging on a single breakpoint.
• Click the Breakpoint button in the debugger toolbar to disable all breakpoints at once.
• Or go to Debug → Deactivate Breakpoints in the top menu.

To remove a breakpoint

• Right-click the breakpoint icon and select Delete Breakpoint.
• Or open the Breakpoint Navigator (⌘ + 8) and delete it from the list.

Want to see an example of how it works? Happy to provide one for you.

An Xcode breakpoints example

Imagine you are investigating a function that returns unexpected results:

func randomFunction()->Int {
    let randomNumber = randomInteger()

    if randomNumber.isOdd() {
        return randomNumber + 1
    } else {
        return randomNumber - 1
    }
}

To understand what is happening, you set a breakpoint on line 53, just before the conditional logic runs.

When execution reaches this breakpoint, Xcode pauses the program and highlights the next line that will execute.

In the debugger panel below, you can see the current runtime values of variables such as randomNumber and self.

This allows you to verify whether the function received the correct value before the conditional logic runs.

How to inspect variables using breakpoints

So we’ve gone through how to set and forget our breakpoints. But how do we actually use them when they’re up and running? Again, it’s pretty straightforward.

When execution pauses at a breakpoint, the debugger panel at the bottom of Xcode shows the current state of the program.

Instead of simply reading values, the goal is to verify whether they match the expected behavior of the code.

When inspecting variables, look for:

• unexpected values returned by functions
• incorrect parameters passed to methods
• variables that change earlier than expected
• objects that are nil when they should exist

When we compare the actual runtime values with what the code should produce, it becomes much easier to pick up logic errors or incorrect assumptions.

If a value is already incorrect at this point, the bug likely occurred earlier in the execution flow, which is where stepping through the code becomes useful.

Step through code using the Xcode debugger

Breakpoints pause the program, which is great. But it’s not just about stopping the program – it’s about seeing what happens next, right?

Instead of placing multiple breakpoints throughout the code, the debugger allows you to step through execution one line at a time.

The debugger toolbar in Xcode provides several useful controls:

• Continue (▶) resumes execution until the next breakpoint.
• Step Over executes the current line and pauses on the next line.
• Step Into enters a function call so you can inspect its implementation.
• Step Out finishes executing the current function and returns to the caller.

Using these controls, you can follow the exact path the program takes during execution.

When you’re debugging complex conditions, nested function calls, or long chains of logic, you’ll be particularly grateful you read this last bit.

Advanced breakpoint types in Xcode

If you want to really get down into the plugs and wires of your code, Xcode’s advanced breakpoint types will take you there.

Conditional breakpoints

A conditional breakpoint pauses execution only when a specific expression evaluates to true. This is useful when code runs many times (for example inside loops) but the bug appears only under certain conditions.

How to add a conditional breakpoint

1. Add a normal breakpoint by clicking the gutter next to the line number.
2. Right-click the breakpoint icon and select Edit Breakpoint….
3. In the Condition field, enter a boolean expression such as:
   • index == 50
   • user == nil
   • response.statusCode != 200

Xcode will stop execution only when the condition becomes true, which allows you to capture the exact moment a problem occurs.

Symbolic breakpoints

A fellow coder once said to me that if a regular breakpoint is like a security camera, a symbolic breakpoint is like a biometric scanner. It allows you to pause executions wherever they occur, even if you don’t know where and when they’ll be called.

Instead of attaching the breakpoint to a file and line number, you attach it to a symbol name.

How to add a symbolic breakpoint

1. Open the Breakpoint Navigator from the left sidebar.
2. Click the + button in the bottom-left corner of the navigator.
3. Select Symbolic Breakpoint….
4. Enter the symbol name (for example UIViewController.viewDidAppear).

Xcode will pause execution whenever that method is called, anywhere in the app. This is particularly useful when debugging system frameworks, UIKit behavior, or third-party libraries.

Exception breakpoints

An exception breakpoint is pretty self-explanatory. It pauses execution whenever the program throws an exception. Instead of letting the app go on and crash, the debugger stops exactly where the error occurs, making it much easier to identify the cause.

How to add an exception breakpoint

1. Open the Breakpoint Navigator in the left sidebar.
2. Click the + button in the bottom-left corner.
3. Select Exception Breakpoint….

You can configure it to pause on all exceptions or only uncaught exceptions.

Exception breakpoints are one of the fastest ways to locate crashes because they stop the program at the moment the error happens, rather than after the app fails.

Tips for using breakpoints in Xcode effectively

These techniques might seem trivial. But speaking from long (and often painful) experience, they will help you narrow down where problems occur and make your debugging sessions much faster.

Tip	Why this helps
Place breakpoints before complex logic	Lets you verify inputs and state before the code changes values
Inspect variables as soon as execution pauses	Confirms whether the program state matches your expectations
Use Step Over to follow execution line by line	Helps identify where logic diverges from what you expect
Add temporary breakpoints while investigating	Allows you to isolate a specific part of the code without stepping through everything
Use conditional breakpoints in loops	Prevents the debugger from stopping hundreds of times during repeated iterations

Final thoughts

Xcode breakpoints are one of the most effective tools for understanding how an iOS app behaves at runtime.

By pausing execution, inspecting variables, and stepping through code, developers can quickly identify logic errors and unexpected behavior during development.

However, once an app is running on real devices, reproducing bugs becomes much harder.

Tools like Bugfender help by collecting logs and debugging information directly from users’ devices, making it easier to investigate issues that appear in production.

If you want better visibility into real-world crashes and bugs, you can create a free Bugfender account and start capturing logs from your apps.