NSLog is a fun debug tool, but it has no place living in your version control history. Those of you who came from other languages and platforms might be used to a world where NSLog’s cousins, console.log, print, puts, and the sort were all you had to try to figure out what was wrong with your code.

In Objective-C we have something much better: breakpoints. I think you get them in Python or Ruby or some such depending on the platform, but I don’t know about those, so I’m not talking about them.

Here’s why the breakpoint is far superior to NSLog for your OS X and iPhone projects:

1. They don’t get mixed in with your actual code.
2. It takes one click or key combo to disable all of them and run your app without noise.
3. You can’t forget to remove them. The binary you distribute won’t print out junk all over your customer’s computer.
4. You can do way more than simply print out things when you hit a breakpoint.
5. They’re not slow like NSLog. Every NSLog statement needs to create a calendar object and date formatter to put a timestamp on your information. These are expensive to create. Gross.
6. You co-workers don’t need to see a stream of information in the console that has nothing to do with what they’re trying to fix.

Sounds powerful, huh? It certainly is. You can even do much fancier things with breakpoints like tell the computer to make noise when your code gets to that spot. If you know python at all, you can have it execute arbitrary scripts to capture any info you like and record it any way you like. If you have an account with Apple, you can check out this video where they spend an hour or so talking about all the god-like power you have — all without tainting up your source code with lines that don’t directly contribute to your customer’s happiness.

There are some times where you need legit logging. You need your app to keep a record of what it was doing. That’s fine, server-based systems do this all the time. Your own computer does it. For logging like this, you need a better solution than NSLog. People have built things like this. Try having a look here for some ideas.

Now you might be thinking “Wow, that sounds so much better, why would I bother with NSLog?” To which I would respond, “Exactly! Glad you liked my article.”

You might also be thinking “dude, I love my NSLogs so much, shame on you for talking bad about them.” To which I’d reply, “sure, sure, use your NSLogs all you like, just don’t commit them and share them with the team.”