Xcode Debugging For Beginner (1): Tools

Debugging, a common practice for developers, can suck up a lot of time and bring deep frustration. Easier and faster debugging is always a pleasant goal. Let’s explore some debugging tools that you can apply right away!

NSLog(Obj -C)/print(Swift)

Printing in Console is a commonly used debugging method, especially when you cannot use a breakpoint in cases like when you cannot add a debugger (e.g. in a production app) or when you try to debug a race condition issue. However, it takes longer time than other debugging methods as it requires you to re-run the app every single time you make a change to log messages. You also need to remember to clean them up after finishing the debugging, especially when the logged messages contain sensitive information.

Basic Breakpoints Usages

One common way to debug without touching the code base is setting breakpoints. All you need to do is click the line number at the left side of your code editing view, and a blue breakpoint arrow will show up.

Here are the most common ways to use breakpoints:

• check a variable in the left panel of Xcode debug area; (To see the properties of that instance, click the arrow at the left of the variables.)
• type po(print object) or print with the variable name in the console directly.

You can show or hide the left and right panels by clicking the two buttons at lower right side of the debug area.

Sometimes you may find that the variable values are not showing, but the error “unable to read data” displays, or the values are shown as nil even though you know it’s a lie. This is usually due to the optimization level in your build settings. Make sure it is set to “None” in the “Debug” configuration. When you use Cocoapods and try to step into a pod’s code, make sure you check the optimization level in the Pods project’s corresponding pod target.

The basic breakpoint tool can solve a lot of debugging needs but not all of them. When you want to debug a race condition, stopping at a breakpoint is never the best way. Another case is when you don’t know where to put a breakpoint. For example, you want the program to stop at the place where it throws an error. To debug these cases, we need to dive into more advanced breakpoint usage.

Advanced Breakpoints Usage

More types of breakpoints

In the left side of the Xcode, click the breakpoint icon in the navigation area. You can see a “+” button at the lower left corner, which allows you to add different kinds of breakpoints. Here are some commonly used breakpoints types:

• “Exception Breakpoint” is recommended to catch exceptions and show related information.
• “Symbolic Breakpoint” allows you to stop at a method that you have no access to. It is usually used to stop at a method of third party libraries or iOS frameworks. E.g., you can use -[UIViewController viewDidLoad] to create a breakpoint for that method.

Temporarily disable breakpoints

You can click on the breakpoint to enable/disable it. You can also drag a breakpoint to another line or drag it to the code edit area and release the mouse to delete it.

Editing breakpoints

Right click the breakpoint will show you the options of editing the breakpoint. Click the “Edit Breakpoint…“.

Now you can customize the breakpoint. One of the most useful things here is adding extra actions for the breakpoint:

Here are different types of Actions and their usages:

• “Log Message” allows you to log messages at run time without touching the code.
• “Debugger Commands” accepts whatever commands for console.
• “Sounds” is the best when you just want to know if a line of code is called or not, when it’s called, and how many times it’s called.

You might notice the option “Automatically continue after evaluating actions”. This allows you to debug without stopping the code, which can save some time and clicks on the “Continue” button.

With Debugger Command, you can also change a variable at run time by using expr as following:

Memory debugging

Memory leaks are one of the most common issues in programming, which are often hard to debug. Besides reading through your code again and again to find the leak, you can also use Xcode to check each thread stack trace and the map of created objects. All you need to do is to right click on the project in the debug panel. Here are some screenshots of what to expect from the Xcode.

View Process by Thread

View UI Hierarchy

When there are too many UI elements and you cannot see small components, you can drag the sliders to pull the UI elements further away from each other for a clearer view of the hierarchy. You can also click on one of the views to see more detail in the debug panel on the left.

View Memory Graph hierarchy

This shows your the objects in the program. You can click the arrows of some objects to expand the map.

Conclusion

Here I introduce the most common and easy-to-use debugging tools. They should cover most of the common debug cases. If you are interested and want to dig more, try Chisel, a great place to play around.

Now that you know more tools for debugging, does that mean you know how to debug? If you are not sure about that, it’s ok! I am going to writing another article to introduce some debugging strategies which will help you debug more efficiently. Please stay tuned. :)