As most iOS app developers are aware, breakpoints are an important part of debugging apps. In Xcode, using a breakpoint is as easy as clicking on any number on the number line on the left side. By clicking on a number, you are pausing the execution of the app at that point. When you pause the app, you can view the state of any variable in scope, issue commands to the debugger, and even view the code line by line and watch the execution flow unfold in front of you.
To make your breakpoint experience while debugging even better, we will be covering the 5 breakpoints every iOS developer must use.
The breakpoint navigator
Managing breakpoint is easy in Xcode. You will find the breakpoint navigator in the navigation panel on the left side of Xcode. Here, you can view all the breakpoints that are currently set in your project. Click on the name of the method or click on the breakpoint icon to enable/disable it and removing it is as easy as dragging it outside the panel.
Symbolic breakpoints
Although it is useful to set breakpoints on a specific line of code, it will also be helpful if we could use the symbolic breakpoint. You can click on the ‘+’ at the left bottom of the breakpoint navigator and choose the symbolic breakpoint. These breakpoints trigger on certain conditions like anytime a certain method is called on a class.
Top 5 Xcode breakpoints
Objective-C exceptions
This breakpoint catches all exceptions thrown by Objective-C code. It is not as useful now due to the transition to Swift but this is still useful if you have any code written in Objective-C. It is also useful in case you are using any third party libraries written in Objective-C.
How to use:
Add the exception breakpoint
Change the exception value to Objective-C
Click on Add Action to add it to the debugger command
Type po $arg1 in the command. It will automatically print the error in the console when it encounters an error
UIApplication Main
This breakpoint is used at the entry point of your application’s launch. Using this breakpoint will make the debugger more aware of properties and methods on things like UIView. This makes it easier to interact with and print properties when you’re debugging.
How to use:
Add the symbolic breakpoint
Type UIApplication Main in front of symbol
Add the debugger command action
Type expr @import UIKit in the command
Check the box, Automatically continue after evaluating actions. This ensures that your app does not pause every time you build and run
UIViewAlertForUnsatisfiableConstraints
This breakpoint helps in undesirable constraint consideration. Most mobile app developers may have come across an error message in the console that says, ‘unable to simultaneously satisfy constraints’. It suggests you apply breakpoints. Such errors will not cause any visual errors but they must be fixed since you may not know how the other versions of iOS will handle these errors. Xcode 9 also provides a new ‘Constraint Error’ which you can use instead of the symbolic breakpoint.
How to use:
Add the symbolic breakpoint
Type UIViewAlertForUnsatisfiableConstraints in front of symbol
-[UIView(UIConstraintBasedLayout) _viewHierarchyUnpreparedForConstraint:]
This breakpoint helps you identify and understand the auto layout constraints. Most developers use this breakpoint a little less than UIViewAlertForUnsatisfiableConstraints breakpoint but it is still advisable to go ahead and use this one.
How to use:
Add the symbolic breakpoint
Type -[UIView(UIConstraintBasedLayout) _viewHierarchyUnpreparedForConstraint:] in front of symbol
UICollectionViewFlowLayoutBreakForInvalidSizes
This helps you catch layout errors in the UICollectiveView flow. It is helpful if you are working with self-sizing collection view cells or happen to create your own flow layout subclass.
How to use:
Add the symbolic breakpoint.
Type UICollectionViewFlowLayoutBreakForInvalidSizes in front of symbol.
