Unstable iOS logging

[ktbeaver]

Hi there,

We have noticed that the iOS build currently fails or crashes due to KotlinLogging and the explicit use of DarwinKLogger. Unfortunately, the error messages in Xcode are not particularly helpful. If you need further information, we would be very grateful if you could give us some pointers on how we can specifically support you in order to better narrow down the problem.

Kotlin Logger Version 7.0.13
Kotlin Version 2.2.0
Gradle Version 8.13

[oshai]

Can you please create a small reproduction project on github?

[ktbeaver]

Can you please create a small reproduction project on github?

Sure, I have forwarded the request to our mobile team. I'll come back soon as they have prepared something.

[oshai]

Any update on this?

[ktbeaver]

Happy New Year to you.

Unfortunately not. Our project manager reduced the priority due to sick notes in the mobile team. I have prepared a small example project but could not test it doe to missing technical devices. Our project is quite extensive, so I have attempted to cover all use cases in this sample project. During our daily meetings, the mobile team has occasionally identified additional iOS build or runtime errors that do not originate from the logging package and are delaying current development. I suspect it's less of a bug in the logging project and more that the different IDEs we use generate different configuration files, thus producing this error map.

Maybe, someone else from a different company reads this post and may share their experience?

Our Setup is:

Backend & Core Dev Team uses Inellij on Linux machines
The Mobile Dev team uses Android Studio and XCode on a Mac

Additionally, I'd like to mention that the used Intellij version in Android Studio is always older than the Intellij version that is installed on the Linux machines.

So, I am still on it and bring the topic back on the table, but I am not in charge to st the priorities.

[oshai]

Can you please try it with the new v8 beta?
We fixed some related issues there.

[ktbeaver]

Use 8.0.00-beta-01 copy we will do.

[ktbeaver]

I got a slot for testing for the last 2 weeks of January.

[oshai]

when you start testing use the latest version that will be available at that time. I am doing some more fixes for #588.

[ktbeaver]

I'd like to inform you that I have pushed a testing branch to our mobile devs with beta-04. When we test, should we look for something else at the same time?

[oshai]

Nothing I can think of right now. Let me know what you find.

[ktbeaver]

Good news: No errors so far. The project is building and also running.

The mobil team is still on testing various scenarios of usage. One question came up for the Android implementation. Are there all log levels in accordance with an ordered like this?

log4j	Android
FATAL	(???) ASSERT
ERROR	ERROR
WARN	WARN
INFO	INFO
DEBUG	DEBUG
TRACE	VERBOSE

[oshai]

Android Log Level Mapping in kotlin-logging

On Android, kotlin-logging has two modes of operation controlled by the kotlin-logging-to-android-native system property.

1. Default Mode (SLF4J)

By default (if the property is not set), kotlin-logging acts as a standard SLF4J client.

• Behavior: It delegates log calls to an SLF4J provider.
• Internal Mapping: kotlin-logging maps levels 1:1 to SLF4J levels (as seen in Slf4jExtensions.kt):
  • TRACE -> TRACE
  • DEBUG -> DEBUG
  • INFO -> INFO
  • WARN -> WARN
  • ERROR -> ERROR
  • OFF -> (Not Supported / Throws Exception)
• Android Mapping: The final mapping from SLF4J to Android Log levels depends entirely on the SLF4J binding you are using (e.g., slf4j-android, logback-android).

2. Native Mode (kotlin-logging-to-android-native set)

If you set the system property kotlin-logging-to-android-native to any non-null value (e.g., "true"), kotlin-logging bypasses SLF4J and uses its own AndroidNativeLoggerFactory.

Configuration

System.setProperty("kotlin-logging-to-android-native", "true")

Log Level Mapping

In this mode, the mapping is explicit as defined in KLoggerAndroid:

kotlin-logging Level	Android Log Level	Method Used
FATAL	(Not Supported)	(None)
ERROR	ERROR	Log.e()
WARN	WARN	Log.w()
INFO	INFO	Log.i()
DEBUG	DEBUG	Log.d()
TRACE	VERBOSE	Log.v()

Summary & Common Concepts

• No FATAL/ASSERT: In both modes, kotlin-logging does not support FATAL or ASSERT levels. The Level enum is limited to TRACE, DEBUG, INFO, WARN, ERROR (and OFF).
• Android Verbose Mapping: To ensure TRACE maps to Android VERBOSE (instead of relying on SLF4J binding), you must define the kotlin-logging-to-android-native system property.

[ktbeaver]

All test runs were successful, including in the project itself.

Used version 8.0.00-beta-04