Under the Bridge


So everyone who’s done any Cocoa programming probably has an NSLog wrapper conditionally compiled on DEBUG for their development ease, but we seem to have seen quite a bit of gushing lately about this NSLogger project on github, so let’s take a look at the description and the Slideshare presentation here and see if it’s really all that, shall we?

NSLogger is a high perfomance logging utility which displays traces emitted by client applications running on Mac OS X or iOS (iPhone OS). It replaces your usual NSLog()-based traces and provides powerful additions like display filtering, image and binary logging, traces buffering, timing information, etc.

NSLogger feature summary:

  • View logs using the Mac OS X desktop viewer, accept connections from local network clients (using Bonjour) or remote clients connecting directly over the internet
  • Online (application running and connected to NSLogger) and offline (saved logs) log viewing
  • Buffer all traces in memory or in a file, send them over to viewer when a connection is acquired
  • Secure logging (connections use SSL by default)
  • Advanced log filtering options
  • Save viewer logs to share them and/or review them later
  • Export logs to text files
  • Open raw buffered traces files that you brought back from client applications not directly connected to the log viewer
  • You’ll find instructions for use in the NSLogger wiki.

Your application emits traces using the NSLogger trace APIs. The desktop viewer application (running on Mac OS X 10.6 or later) displays them.

Clients automatically find the logger application running on Mac OS X via Bonjour networking, and can optionally connect to a specific remote host/port. You have no setup to do: just start the logger on your Mac, launch your iOS or Mac OS X application then when your app emits traces, they will automatically show up in NSLogger if the viewer is running locally on your network. Until a logger is found, logs are buffered on the client so you don’t lose anything…

Oh-kay, that is indeed the Unquestioned Champion Of Hardcore Logging Frameworks that we’ve ever heard of, certainly. Particularly of note is logging images directly — we can think of more than a few times that would’ve been kinda handy — and these remote features, why we can think of many instances indeed these would have been wonderful:

  • Instrument your code to use a logger you instantiate on demand, in a release build. Combined with the ability to connect to the viewer remotely over the internet, this lets you distribute builds to testers or even customers, that have the capacity to connect directly to your viewer when running. One of the potential uses is live troubleshooting of issues in software running at remote locations.
  • Buffer logs to a file that you can later transmit to a server. The NSLogger desktop viewer can read this raw file (provided that is has the .rawnsloggerdata extension).

So yes, next time you have teh hardcore debugging needs, looks like this would be an excellent tool to pull out of your bag of tricks. Strikes us as just a little too much effort to go to without an obvious reason, so we’ll stick with our pretty basic DEBUG-conditionalized and not Objective-C dependent twlog() family of macros for the usually minimal logging needs we have … but next time we have one of Those Problems that just plain don’t appear on our test devices no matter how closely we follow the client instructions, yes out comes NSLogger to show us just what on earth is happening in the wild wacky client world, no doubt!

h/t: @holtwick, @openiphonedev!

  • Florent Pillet

    Thanks for mentioning NSLogger — I have crammed so much functionality in this tool that it can seem daunting at first. With only two lines of code, though, you can adopt it and keep it always there in your app so you can flick the switch the day you need it.

    The first line is obviously a logging macro that replaces NSLog():

    #include “LoggerClient.h”
    #define NSLog LogMessageCompat

    From that point on, you’re using NSLogger (well that was actually two lines). Simple enough, uh?

    The second line you want to add, if you don’t want to run the OS X viewer app, is (i.e. in your application launch method):

    LoggerSetOptions(NULL, kLoggerOption_LogToConsole);

    And that’s all. Now all your logs are going to the Xcode console, like in good old times. So why would you want to use NSLogger instead of plain NSLog() just for the console?

    Two reasons:
    – Log serialization: all console output is performed from the internal thread NSLogger creates for you. This means that even if you NSLog() from multiple threads at the same time, you’ll never see intermixed output anymore
    – Log beautifying: the console output from NSLogger is a bit more readable than NSLog()’s

    The 3rd reason being that you’ll soon get hooked on using the viewer to quickly find the information you’re looking for. That’s what NSLogger was designed for, to be a data mining tool.


  • Pingback: Tweets that mention NSLogger at Under The Bridge -- Topsy.com()

  • Pingback: NSLogger 1.0 « Under The Bridge()