Today we’re announcing the stable release of our logging library Kermit

If you’ve been following me, I’ve given a few talks on Kotlin KMP library development. In my previous talks I gave some suggestions on what kinds of libraries the community needs. I went out of my way to say avoid building logging libraries. Even way back in 2019, there were already a few options for KMP, so I assumed that topic was handled.

Don’t build logging libraries

After doing some digging, though, nothing really felt like it was done the way we wanted. Also, in early 2020, due in part due to circumstances we’re all aware of, we had a few more hands available than planned. We had wanted everybody on the team to get a chance to work on a KMP library, and logging libraries are, if nothing else, conceptually straightforward. After some general architecture chats, the team dove in and made a dev version of Kermit.

The plan was to try it out, get some feedback, then make a 1.0 and tell everybody!

Then we got super busy.

The good news is we got some extra time to think about the library design, and a lot more feedback than you’d think for something we never quite announced.

With that feedback, plus more lessons learned shipping KMP code in the meantime, we sat down and made a plan for Kermit 1.0.

Kermit 1.0

Kermit has a simple API, is easy to extend, and is focused on performance. Getting started is very easy, but Kermit provides more sophisticated configuration as you move beyond dev into releasing your applications.

Rather than a single long post that I’ll never finish, we’ll wrap this up with basic setup, then go deep on a few other topics in future posts. The list is subject to change, but look for posts on basic setup and usage, production setup, crash reporting integration, and a deep dive on the performance considerations that went into the design.

Note: Kotlin 1.6.0 publishing issues

To clarify some confusion around releases, we originally published 1.0.0 for Kotlin 1.5.31, then this post got delayed a bit. When Kotlin 1.6.0 came out, we ran into some Kotlin/Native stuff that needed fixing, but ultimately pushed Kermit 1.0.2 with Kotlin 1.6.0. However, it turns out Kotlin 1.6.0 has Android publishing issues, so please use Kermit 1.0.0 until Kotlin 1.6.10 releases, which should be in a couple weeks.

Getting Started

In your Kotlin Gradle config, add the Kermit dependency in `commonMain`.

commonMain {
 dependencies {
   implementation("co.touchlab:kermit:1.0.0")
 }
}

Without any other configuration, you can use the global Logger with default log writers per platform. For Android, it writes to android.util.Log, iOS logs are written with println, and JS goes to console.

For iOS we replicated a good idea from Napier. Color coding the iOS logs. Format is slightly different, but same concept.

iOS Color Coded Output

To write logs with the global logger, just do this:

Logger.i { "Hello" }

The log calls are lambdas, which will allow us to avoid creating strings if they’re not needed, but you can also call “regular” methods with a string.

To log an exception:

catch(ex:Exception){
 Logger.e(ex) { "Something happened" }
}

To change tags, do this:

val l = Logger.withTag("DifferentTag")
l.i { "New logger, new tag" }

That’s it for today. Again, keep an eye out for other posts about Kermit. Please share feedback, star the Github repo if you like it.

Work at Touchlab!

We’re hiring! If you want to help define the future of Kotlin, and like living a bit on the edge technically speaking, please reach out!