SwiftyBeaver configuration: Common options

In this lesson

In this lesson, I will step through the most common SwiftyBeaver configuration options.


Tap on time to skip ahead


Hello everyone! In this lesson, I’m going to talk about configuring SwiftyBeaver. In order to do that, let’s head over to the sources folder. I’m here at the GitHub repo. In other lessons, I talked about the various destinations that you can setup with SwiftyBeaver, that being the ConsoleDestination, the FileDestination and the SwiftyBeaver Platform Destination. Most configuration that you perform against SwiftyBeaver will be done against the destinations. And all 3 of those descend from this BaseDestination class. So if we navigate into that and look at the class definition, up top, all of this is basically configuration that you can make against each and every destination. And conveniently, SwiftyBeaver has some useful defaults so in many cases you really don’t need to do anything. We’re going to talk about what you can do if you so choose.


I should note that in this lesson, I’m only going to cover these configuration options here that I’ve highlighted. These 3 down here are not used as much in my experience and I’ll cover those in a different lesson.


The first thing we’re going to look at is detailOutput. You’ll notice that the default value is true which means if you look at the comment, that it includes in the log statement, the file, the function and the line. That’s true, that’s what you want most of the time but I’m going to show you what it looks like both on and off.


I’m here in the AppDelegate of my sample application and I’m going to navigate to the area where I configure the logger, in the initializeLogger() function. All of my examples here today are going to focus on the ConsoleDestination. However, I could apply the same configurations to the file and/or SwiftyBeaver platform destinations.


The effects of those will apply equally across all 3. For brevity, I’m going to focus here on the console. What you’ll notice here is that in the ConsoleDestination configuration, I’m simply creating a new instance and adding it. So I’m not making any specific configuration choices here. But if we look at a single logged line, we can see how SwiftyBeaver applies the settings that we make to that. You’ll notice that each line has a date. It also has a class and a function and a line number, as well as the logging level that we logged at and the message that we logged. So by default, you get these without making any configuration changes.


I’m going to turn details off; detailOutput… if I can type here, detailOutput = false. So this is the first configuration I’m going to change and I’m going to re-run my app and we’ll see what it looks like. We can see the effect here in the console of turning detailOutput off. You’ll notice that we no longer display for each log statement, the class, the line number or the function.


The next thing we’re going to look at is the colored property. It’s defaulted to true, which means the level descriptions in our log statements are colored, but I’m going to turn that off and show you what that looks like. I’m back over here in the AppDelegate and you’ll notice the level statements are colored, but I’m going to turn that off in the code; consoleDestination.colored = false. I’ll run that can show you what that looks like.


What you see here in the log is if I turn colored off you’ll notice that the log level text in the log is just black like the rest of the text.


Next up is the colored lines property set to false. Let’s turn that on and see what that looks like. So once again let’s set the coloredLines property to true. And I will run that and we’ll see what the output looks like. What we can see here in the log is that instead of just the text of the log level being colored, the entire log level and the message itself is colored. So that’s a nice little feature. Definitely makes things stand out.


The next configuration property is called asynchronously and there’s really nothing to show here. But this defaults to true and what that means is that any logging will be done on a background thread as opposed to the calling thread. So that’s actually something you probably always want to leave true. Otherwise, things that you log from the main thread, for example, will be logged itself on the main thread. And that will impact your user’s experience. Generally, you want to leave that true.


The last thing I want to cover is the minLevel setting. It defaults to .Verbose and by setting this, it will impact what actually goes to that destination. Since it’s .Verbose by default, that means everything you log will go to that destination. And I’m going to change this to a higher level to show you the impact that this has in reducing the noise in your logs. If we look here at the log, you’ll notice that it’s quite large. That’s because the destination is configured to log everything. The minimum level is set to .Verbose, which is the lowest possible logging level in SwiftyBeaver. I’m going to change that and set the minLevel to be something higher; SwiftyBeaver.Level.Info And so the only thing that’s going to be logged is .Info, anything at .Info or higher. So let me run that and see what impact that has on our log.


If we take a look at the impact of this, you’ll notice that no more .Debug or .Verbose statements in the log and the log is actually quite short. The only thing that shows up are .Info, .Warning and .Errors, which I don’t have any .Errors. So by using the minLevel property on the destination, I’m able to drastically cut down on the noise. Sometimes I want that, sometimes I don’t. But setting this property will allow you to control the minimum level of statements that will appear in the destination. So there you have it. I talked about the various, most common configuration options for your SwiftyBeaver logging destinations.