NSLog(): The First Line of Defense Against Bugs

If you’ve spent time among other iOS developers or gone on Stack Overflow, you’ve probably heard someone mention the NSLog method, or perhaps println, a more primitive Swift logging function. This is the first—and often the last, unfortunately—piece of debugging advice new developers receive. We first saw it way back in ​for Loops​, and have used it occasionally throughout the book, usually as a placeholder to make sure our app reached the new code we were writing.

The gist of NSLog is that it will print a time-stamped message to the console that only we will see. It might seem counterintuitive to create output that only we will see, but it is vitally important to have some means of verifying what is happening in our program. NSLog output also goes to a system log file, so we can collect it from beta testers to illuminate problems with our app.

Let’s put ourselves in a situation where we might want to use NSLog to find our way out. In RootViewController.swift, find the reloadTweets method, and change the URL it uses, like this:

Of course, there is no Twitter API call at the endpoint https://api.twitter.com/1.1/statuses/foo_bar.json, but this isn’t a completely unrealistic scenario either. We might have mistyped the URL, or the web service API might change and remove something we were counting on. At any rate, when we run the app, we come upon an empty table. Pull to refresh, and it’s still empty.

If we didn’t know the root cause was the bad URL, we’d have to think of reasons this might be happening. We might be parsing the JSON incorrectly. It’s possible the table is not connected to the view controller, causing self.tableView.reloadData() to do nothing. Or the delegate might not be connected, so we’d never get callbacks to tableView(rowForCellAtIndexPath:). We can mentally walk along the path our code takes from the refresh to the updated table, as shown in the following figure, in order to figure out where the problem might be, but we can’t verify it without running some kind of test.

As you can see from the figure, there are at least four points in the operation where something could have gone wrong—maybe more, when we consider that some of these steps have multiple steps within them. We don’t need to add an NSLog after the last operation because we already have observed that the table did not update.

By setting up feedback for every step in the process, we can now observe at what point in this chain the message breaks down: the request is sent, and the response is parsed (to some degree), but we never update the table. By throwing down a bunch of NSLogs, we can at least focus our search on handleTwitterData, since we reach that method but it fails to update the table.