Swift Components Tour – Breakpoint Basics

In this lesson

Back in the Swift Components Tour app, let’s talk over a short introduction to one of the most useful debug tools, breakpoints.

Kyle Roberts
Swift Guru at Large

Kyle's Series


Tap on time to skip ahead


Hello world, Kyle here with Brax.tv and today we are going to talk about debugging with breakpoints. If you don’t know what a breakpoint is, or how to use it in Xcode, that’s what we’re going to cover here. You’ll see some of the cool things that you can do with them and how they are useful.


A breakpoint in Xcode and iOS is basically a little flag or symbol that you can put in your code just by clicking in this left border bar over here in the editing area. What happens when you have a breakpoint is that whenever this code is run, and the breakpoint- the line that the breakpoint on is about to run, then the current debug session that you have going on will pause, and you will get a snapshot of the code and the classes and the property that are at the scope where your current breakpoint is. That’s great to maybe see if there’s something fishy going on. You can look through all the properties and find out what’s going on.


You can see here that in the code, I just put down a random breakpoint and the TextFieldViewController on viewDidLoad. So viewDidLoad is called before the view controller appears, the view controller’s view appears, so when I do open this text field’s view controller, before the view controller actually appears or is open, we hit this breakpoint. The run time is paused. Down here next to the console output in this debug area and above the breakpoint navigation menu, right here, we can see all of the current objects in the scope of where the breakpoint is at at the moment.


All we have access to right now is self. Self is an instance of the NIOTextFieldViewController, in the app Swift Components Tour and these letters and numbers here are like it’s reference something more complicated, is nothing to worry about right now. We can twirl that open and see everything we currently have access to at that moment in self. Which is an instance, again, of the NIOTextFieldViewController. The first object under self is actually still self but referencing it’s base class. Which right now, it’s base call is NIOBaseDetailViewController. If we had some public properties in NIOBaseDetailViewController, we would be able to see them right here. And even under that we can see NIOBaseDetailsViewController Super Class, just UIViewController. The reasons that these don’t have referenced byte things here is because they’re actually the same instance, all three of these, are all talking about self.


Under that we just have any static variables or properties that may or may not have been initialized that this point. The first three here are- the first four here are the IBOutlets that we have referenced here, a label, both text fields and then a constraint. Then, under that we have a timer which is an instance of NSTimer, which has not been initialized yet so it doesn’t have this reference here either. We can see that the current value is nil. Then we have a static array down here of waiting strings. Which, although it is not up near the properties here, it is down above a method that is being used later.


That’s how you place a breakpoint. To skip over a breakpoint and continue the app how it was, you hit this little play/pause button that says continue program execution. You just hit that and we’re back in the app. It’s working as normal. Everything is great. But if we do go back and we open the text field’s view controller again, and it creates a brand new instance of this NIOTextFieldViewController, then we will hit viewDidLoad again even though we have that breakpoint here.


Also, there’s nothing wrong with using a bunch of breakpoints at once. Maybe you are doing something important or changing a value here so that we can place this breakpoint right here and stop it right before this super viewDidLoad call and then we can continue program execution and we’ll actually stop at the next breakpoint, which is right before this self start animating label call. And so on and so on until no breakpoints are hit and the app is going to keep going as normal unless we run into another breakpoint. Which we do not. I hope that’s a nice little intro of what a breakpoint is and how to use it. Thanks for watching.

Additional Info

Register to get access to additional resources and info.