Swift Logging with XCGLogger

When Swift was released earlier this year there was the inevitable rush to get some type of logging framework out there to use. CocoaLumberjack, still one of my favorite logging frameworks for iOS development, made enough use of the C preprocessor to make working with it in a Swift application a pain.

Fast forward to today and Lumberjack has put a lot of effort in becoming more Swift-friendly, but in the interim @DaveWoodX released a native Swift logging framework known as XCGLogger.

One of the things I look for in a logging framework is how quickly I can go from zero to logging. If the instructions require CocoaPods or importing the logging project into my project or git submodules, well, you can forget it. Here’s where XCGLogger shines in my opinion. Let’s take a look at how easy it is to add logging to a Swift project with XCGLogger (so easy I don’t even feel compelled to provide screenshots!).

Go to the XCGLogger Github page and click the Download ZIP button on the righthand side of the page. In your Downloads folder will be a new folder named XCGLogger-master. Open and head straight to XCGLogger – Library – XCGLogger. Drag-and-drop the single XCGLogger.swift file into your project navigator ensuring that you select Copy items if needed.

Now, in your AppDelegate.swift add the following after your imports but before your class declaration:

In your app delegate’s didFinishLaunchingWithOptions function add:

To test things out you can add a log.debug("Test") right after that. Build and run your project. You should see the following in your console:

And really that’s it. It was so easy in fact we feel a little guilty, so let’s add the ability to log entry and exit points for functions. Create a new file, LogUtils.swift and add the following:

To test it out you can instrument one of the viewDid or viewWill routines of a view controller. Here I add instrumentation to viewDidLoad:

Running again and you get:

All of this by dragging and dropping a file out of the XCGLogger project into ours, and then adding a bit of wrapper for ENTRY_LOG and EXIT_LOG.

Using Swift build flags we can refine this even further by adding something along the lines of:

If our build configuration doesn’t include -DDebug then our debugging severity level will be set to .Severe. We could have also use .None to eliminate logs altogether.

Some might rightfully point out that the preprocessor mechanism employed here would be superior because it would allow for stripping out all of the code calls for logging. This is true, but I’m going to wager that if your application is having size or performance issues its not because of your logging instrumentation.

Note: This is by no means an exhaustive summary of XCGLogger’s capabilities (it can be configured to write to files instead of the console, for example) and whether or not the drag-and-drop method of adding only XCGLogger.swift is officially supported, I don’t know. Let’s hope it remains so easy as a great logging framework should be! For more information on XCGLogger see the official Github repository.