Hey everyone I just released my first library for ...

# feed

[Prashant]

Hey everyone I just released my first library for KMP - LogKat.

The LogKat is a Kotlin Multiplatform (KMP) library that provides a unified solution for logging across Android and iOS platforms. This library simplifies cross-platform logging by eliminating the need for separate platform-specific code. With a single API, you can log messages that will appear in Android's Logcat or iOS's console, depending on the platform your app is running on.

Key Features
• Cross-Platform Logging: Supports logging on both Android and iOS with no extra setup.
• Unified API: One simple API for logging across both platforms.
• Color-Coded Output: Logs are color-coded based on severity (Info, Debug, Warning, Verbose, Error) for easy identification.
• Platform-Specific Output:
• On Android, logs are sent to Logcat.
• On iOS, logs appear in the console (stdout), ideal for debugging.
https://github.com/prashant17d97/LogKat

I would love and really appreciate your feedback.

[Michael Paus]

And what’s the advantage over a well established true multi-platform logger like, e.g., https://github.com/oshai/kotlin-logging

[Stefan Oltmann]

We've got quite an inflation of logging libraries these days! 😅

[Stefan Oltmann]

Maybe it’s time to write my own. 🤔 😜

[marlonlom]

🤔

Exception in thread "main" com.myproject.exceptions.TooManyLoggingLibrariesOverflowException: Too many logging library ideas!

[Alexandru Caraus]

What is the best kotlin multiplatform logging library?

[Alexandru Caraus]

The one you write yourself, badum tsss!

[kqr]

and I still don't know which one to use

[Stefan Oltmann]

Just write your own. 😉

[Stefan Oltmann]

The last time I checked, Kermit was still quite popular.

Back in the day, I also ended up writing my own logging "framework" for Ashampoo Photo Organizer. 😅

I heavily rely on Sentry.io for logging, so my API primarily consists of a bit expect/actual code.

[Stefan Oltmann]

JetBrains could stop this by at least providing a SLF4k (simple logging facade 4 kotlin) as part of the standard api.

You know, like SLF4j is popular for a reason.

[suresh]

Just write your own.

Writing a good logger (like Logback or Log4j2) is not an easy task, especially if we want to support Kotlin/Native. I tried to implement one for a CLI app targeting Kotlin/Native, with support for file rotation and size policies, but eventually dropped the idea as it was too time-consuming 😕 . It’s unfortunate that we still don’t have a good logging library for Kotlin/Native targets.

least providing a SLF4k

Agreed and one for db access also (like jdbc)

[Casey Brooks]

A basic logger that outputs text to LogCat/OSLog/stdout/etc. is pretty simple to write, and often the cost of manually writing this logger yourself is lower than the cost of managing updates for a dependency.

In contrast, each project’s individual needs or preferences for a logger can be quite varied, and it’s difficult to capture the needs for robust or structured logging (such as logs that one needs in a server environment) in a way that makes everyone happy. Structured loggers need deep integration with the runtime environment to avoid performance degradation (writing logs is IO, and thus an expensive operation at scale).

IMO, the reason SLF4J is popular is…because it’s popular. It’s a bit circular, I know, but it doesn’t really provide anything special in itself, because it is just an interface. One needs to combine it with another library like Log4j to provide the actual logging functionality, and those libraries are huge and complex things which can be catastrophic if implemented incorrectly. SLF4J’s ubiquity and the fact that there are multiple loggers it integrates with is the main selling point, rather than providing any unique advantage in itself.

So to that point, Stefan is right, that I don’t think we will get anything close to a standard logger unless it is provided by Jetbrains, because only then would it potentially get a critical mass of folks willing to adopt that standard. But realistically, any JB logger would either be incompatible with SLF4j, and thus make it worthless in Ktor, Spring, and other server environments; or else it would have to be compatible with SLF4J, at which point why not just use that instead? A multiplatform wrapper around SLF4J might be helpful, but some of its functionality (like MDC) is more-or-less incompatible with Coroutines because it relies on ThreadLocal data, so it’s unclear how to provide a good mapping between the two.

Not to say that an SLF4J-compatible multiplatform wrapper can’t be done, as Ktor basically wraps its logging around SLF4J. But the varied platforms that Kotlin runs on poses some real challenges to a logger that’s good enough for folks to choose it over just writing their own logger, especially since there is already so much competition in this space. No one is going to want to refactor their app to change logging libraries, so it will be a long, slow road to adoption which makes the use-case for building it unclear.

[Stefan Oltmann]

Good write-up! 💯 👍

Yes, I meant that if the Kotlin standard library at least provided interfaces - ideally fully compatible with SLF4J on the JVM side - we would be one step further. I've always preferred using SLF4J because it allows me to switch logger implementations without having to modify every file.

[Stefan Oltmann]

In my last Java project, I implemented the logger myself (migrating from Log4j) to meet specific requirements. Since I made it SLF4J-compatible, no other code needed to be changed. That's the power of using a standard interface.

[Alexandru Caraus]

What is the problem with defining your own interface with logging methods for the app, and then the implementation could be whatever, even println?

[Alexandru Caraus]

For example on android this fancy things are not needed.

[Casey Brooks]

^ that’s basically what most libraries do right now, since there is no established interface that libraries can adopt. And it totally works, but it makes it difficult to integrate multiple libraries and aggregate their logs to a single, centralized location. You end up needing to choose your logging library, then write a bunch of “adapters” which connect each library to the main logger. In addition, not every library will even offer a logging interface, instead choosing to write their logs directly to println or LogCat, which further complicates the process of aggregating and understanding your apps’ logs.

In Java-land, SLF4J is the adapter, and all those libraries basically get wired up automatically, so you don’t really notice this process as much. But the the aforementioned reasons, it’s difficult for everyone to agree on what that standard should be, considering it’s almost certainly easier to just do what everyone’s doing now, and provide their own logging interface for the library.

[Alexandru Caraus]

Thats why there are so many libraries, you can define your interface and then find a library that matches perfectly with the interface

[Michael Paus]

That’s why I switched to kotlin-logging which I linked to already above. On the JVM it is basically a wrapper around SLF4J and you can put any actual logger beneath it that you like. On other platforms it falls back to the native logging facilities. Tested on Desktop, Android, iOS and even WASM.

[Stefan Oltmann]

Ok, thanks for the hint, Michael. Should I switch loggers then kotlin-logging seems to be the next best thing available. 🙂

[Stefan Oltmann]

Thats why there are so many libraries, you can define your interface and then find a library that matches perfectly with the interface

🤔
If Kotlin / Java would support duck typing this would work... But they don't.

[Stefan Oltmann]

But the the aforementioned reasons, it’s difficult for everyone to agree on what that standard should be

That's why I hope JetBrains makes a decision (by including something into stdlib) - preferably a wise one, meaning it should ensure compatibility with SLF4J on the JVM side.