Give your simulator superpowers

RocketSim: An Essential Developer Tool
as recommended by Apple

5 Xcode breakpoints tips you might not yet know

Xcode breakpoints allow us to debug and find out solutions for nasty bugs. Without breakpoints, it would be a fun fest with a lot of print statements everywhere in your code. The basic principles of breakpoints we probably all know but there’s a lot more to discover!

What are breakpoints in Xcode?

A breakpoint can be placed at a certain line of code and pauses your app during execution in order to inspect the state of your app at that point. Breakpoints can be set at any time, before and while your app is running.

An overview can be found within the breakpoint navigator which shows all activated and disabled breakpoints. The debug bar contains a breakpoint activation button to temporary disable breakpoints from pausing your app.

The blue breakpoint activation button in Xcode
The blue breakpoint activation button in Xcode

1: User-defined breakpoints

One of the few things you might do for every new Xcode project you create is adding those handy breakpoints that helped you debug a lot of bugs. This is a redundant process and can be solved with user-defined breakpoints in Xcode.

Moving a breakpoint in Xcode
Moving a breakpoint in Xcode

Once you moved a breakpoint it will be shown in its own section containing all user-defined breakpoints.

An overview of user breakpoints in Xcode
An overview of user breakpoints in Xcode

This will make your breakpoint available in each Xcode project you open. This includes projects created by you as well as projects downloaded from the internet. Any project!

How do you stay current as a Swift developer?

Let me do the hard work and join 19,138 developers that stay up to date using my weekly newsletter:

2: Sharing breakpoints through GIT

Sometimes you find yourself looking at your colleague’s workflow and you realize he has some great and useful defined breakpoints. Instead of asking him about instructions to set up the same breakpoints you can ask him to share them through GIT.

Sharing a breakpoint through GIT in Xcode
Sharing a breakpoint through GIT in Xcode

This will move the breakpoint to its own section with shared breakpoints. This makes it really easy to get an overview of all shared breakpoints.

An overview of shared breakpoints in the breakpoints navigator
An overview of shared breakpoints in the breakpoints navigator

As the breakpoints are shared it’s also a shared responsibility to keep them alive. Therefore, if one of your colleagues decides to remove the breakpoint it will also be removed from your breakpoints list as soon as you pull the latest changes from GIT.

3: Exception breakpoints with a debugger command action

One of the user-defined breakpoints I’ve been using for years now is the exception breakpoint. An exception breakpoint is triggered when a specific type of exception is thrown or caught. Whenever the exception breakpoint would hit I would immediately type in the po $arg1 statement after clicking on objc_exception_throw to get more information about the thrown exception:

Printing out extra information on a thrown exception
Printing out extra information on a thrown exception

This can be easily automated using a defined action in your breakpoint. Any defined actions will be executed at the moment a breakpoint is hit and can be a valuable way to debug your application.

Printing out arguments in an exception breakpoint
Printing out arguments in an exception breakpoint

Of course, now you’ll directly make this a user-defined breakpoint so you don’t have to create this one every time you create a new Xcode project!

4: Symbolic breakpoints

We are often helped during debugging with messages in the console telling us to create a symbolic breakpoint. Probably one of the most known ones is the auto layout related symbolic breakpoint:

// Will attempt to recover by breaking constraint 
<NSLayoutConstraint:0x600000d7aad0 UIView:0x7fbe55e95420.leading == UILabel:0x7fbe55e95d20.leading + 8   (active)>

// Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger.

Symbolic breakpoints are triggered when a specific method or function is called. They can be added from the breakpoints navigator:

Adding a symbolic breakpoint
Adding a symbolic breakpoint

You fill in the keyword in the breakpoint and whenever the symbol is called it will pause your application to start debugging.

Adding a symbolic breakpoint for UIViewAlertForUnsatisfiableConstraints
Adding a symbolic breakpoint for UIViewAlertForUnsatisfiableConstraints

In this specific case, it allows you to navigate quickly to the code that activated the unsatisfiable constraints. Pretty neat!

But isn’t this the constraint error breakpoint?

Surprisingly enough, these errors are not triggering the constraint error breakpoint. According to this thread on the Apple forums, this breakpoint only works for AppKit.

Useful symbolic breakpoints to use for collection view layout debugging

Creating a breakpoint like above but using the UICollectionViewFlowLayoutBreakForInvalidSizes symbol allows you to debug any layout issues with the collection view flow layout. Although it’s still not easy to debug those kinds of issues it will at least point you in the right direction and give you a starting point for debugging.

5: Catching failing tests with a test failure breakpoint

When a test fails you often start navigating through the list of tests to find your failed test. Although this is doable, it’s not really efficient if you’re in your flow. For that, we have the test failure breakpoint which will directly jump to the failed assertion in a test, allowing you to directly start fixing the failed test.

Adding a test failure breakpoint
Adding a test failure breakpoint

Conclusion

That’s it! 5 tips to make better use of breakpoints. Together with debugging breakpoints as a replacement for prints, this is a great way to speed up your debugging workflow.

If you like to learn more tips on debugging, check out the debugging category page. Feel free to contact me or tweet to me on Twitter if you have any additional tips or feedback.

Thanks!

 
Antoine van der Lee

Written by

Antoine van der Lee

iOS Developer since 2010, former Staff iOS Engineer at WeTransfer and currently full-time Indie Developer & Founder at SwiftLee. Writing a new blog post every week related to Swift, iOS and Xcode. Regular speaker and workshop host.

Are you ready to

Turn your side projects into independence?

Learn my proven steps to transform your passion into profit.