Coding is important, as you are building a product. Testing is also a crucial part of creating code, that is you are creating a project that is validated and in some sense correct.
Debugging helps you to work out those little problems and errors that exist in your project.
How are you going to do that, why are you going to do that and what does it give you?
- You will be expected to be aware how to make a Single View Application in Swift, including adding
- The code uses Force Unwrapping liberally, avoiding that is covered HERE
- I’ve made the keyboard resign with THIS technique
Breakpoints: a debugging tool that allows you to pause the execution of your program at a specific point in time
We all make mistakes. In programming these mistakes are often known as “bugs” that get into our software and cause problems.
So how can we know where our particular program is going wrong? One strategy is to see what the particular state of our program is at any particular time.
This article will refer to the
debug area , which is highlighted in Blue in the image below
If it isn’t there in the top-right hand corner of Xcode you can select the following icon, and then the bottom bar should appear in you Xcode view.
Both logging to the console and breakpoints are ways that we can find out what is going on under the surface in our App. This article explains how they might be used!
The quality of life improvement
Pauses click the checkbox
Show tab named and write
Debug into the box.
Now trust me, your life will be slightly (very slightly) easier AND better. Anyway…
This App is a particularly simple one — and it does not use the principles of Dependency Injection or similar — in that it adds together two user input numbers.
Wonderful — we can add two numbers together.
Now the more observant reader will see there is too much force-unwrapping going on, and we are asking for a crash (SPOILER: Validation)
If we make the first number
88339858222222255588, or a similar large number you will experience a crash.
Xcode will help us out and make it immediately obvious where the problem is
but what if we want to know why?
Strategy 1 — Print log
You can print out to the console by using
print (first, second) in the code (I’m putting this into the
addTwoNumbers function). This would give us some insight into the state at the time that the print function is run.
However, if we don’t remove the print statement when we upload to the App Store we will suffer a performance penalty.
So this, works but it isn’t the most professional way to move forwards with your bug hunt.
You can just about see the two red boxes in the image above — the one in the code is where the
Strategy 2 — breakpoint & po
You can add a breakpoint by clicking in the gutter of Xcode. In my case I clicked line 29 (actually on the 29)
Now we need to run the program, and Xcode will stop nicely at this breakpoint, well, point. This will only happen once you have written in the two numbers, and pressed calculate.
Something like the following will display, presenting us with lldb (the Low Level Debugger)
Of course we need to make sure the active breakpoints icon is selected!
Now, back on track in that
debug area we can type
which returns (in that part of the screen)
where we can also
Need some shortcuts? Everyone loves shortcuts!
- Continue / Pause = (⌃ + ⌘ + Y)
- Step Over = (F6)
- Step Into = (F7)
- Step Out = (F8)
So if you are on a breakpoint you can move to the next one by using the shortcut ⌃ + ⌘ + Y. Awesome!
You can even list breakpoints by writing
breakpoint list in the debug area.
You can delete breakpoints by right-clicking on the breakpoint and choosing one of the following options:
As you can see there is a rather lovely
Delete Breakpoint option. Want to wipe them all? You can use
breakpoint disable in the debug area (The confirmation message is
All breakpoints disabled. (1 breakpoints)), and can be undone with
Did you know…
You can set breakpoints up in the
debug area. Say we have already set a breakpoint at line 23 and the code stops then — we can type
breakpoint set — file ViewController.swift — line 24 which adds the breakpoint on the next line. Now unfortunately it doesn’t appear with the nice graphic — but it does rather tell you it has nicely been added.
You can then continue (
⌃ + ⌘ + Y) and you will top at line 24. Awesome!
With breakpoints enabled you can do far more. A Quicklook of a variable (particularly with something like a UIBezierPath)
The quick look icon is rather small, but it is an eye as highlighted in a red box below:
Strategy 3 — conditional breakpoint & lldb actions
You can make a breakpoint that only stops code under a certain condition.
You can setup a breakpoint and then right-click on that breakpoint and select:
You can then write in Swift expressions!
Here the breakpoint will only stop if the
first variable is
We can further improve this, and write an action — this can be an lldb action.
This will print the
first variable to the lldb console — but this would only happen if first is
88339858222222255588 (which renders logging that a little pointless, but you get the idea!).
A better way to get the same result might be to select the action
log message which would (obvs. like) log the message to the console that you would like. You can even set
sounds or run a shell command.
Printing to the console seems all very interesting. However, if you leave them in your code they can impact the efficiency of your code.
Breakpoints are automatically removed from your production code — you can leave them in while you build and deploy. Perhaps for that reason alone, it is a good idea to use breakpoints in your App to see where you might have an error in your code, and how you might work to get rid of those little annoying bugs.
Good luck in finding them!
If you’ve any questions, comments or suggestions please hit me up on Twitter