What You’ll Find in the Debug Navigator
Each application within iOS is made up of one or more threads, each of which represents a single path of execution through the application’s code. Every application starts with a single thread, which runs the application’s main function.
The main thread encompasses the application’s main run loop, and it’s where the NSApplication object receives events. Applications can add (spawn) additional threads, each of which executes the code of a specific method.
Selecting an item in Xcode 4’s Debug navigator causes information about the item to be displayed in the Source editor. For example, selecting a method displays the source code for that function in the Source editor.
Threads per se are way beyond the scope of this article, but that’s okay: Here you’ll be concerned with only the main thread.
Every time you send a message (or make a function call), the debugger stores information about it in a stack frame and then it stores all such frames in the call stack.
When you’re thrown into the debugger because of an error (or if you pause the application by clicking the Pause button on the toolbar), Xcode displays the thread list, and within each thread the call stack for that thread, putting the most recent call at the top. The call stack shows a trace of the objects and methods that got you to where you are now.
Although the trace isn’t really all that useful in this particular context, it can be very useful in a more complex application — it can help you to understand the path that you took to get where you are. Seeing how one object sent a message to another object — which sent a message to a third object — can be really helpful, especially if you didn’t expect the program flow to work that way.
Getting a look at the call stack can also be useful if you’re trying to understand how the framework does its job, and in what order messages are sent. As you’ll soon see, you can stop the execution of your program at a breakpoint and trace the messages sent up to that point.