What is generally recommended for exception report...

# multiplatform

[Mario]

What is generally recommended for exception reporting in a KMM project that supports both iOS and Android?

I've been using Crashlytics but the iOS crashes aren't helpful. It looks like this can be fixed with NSExceptionKt or CrashKiOS, but I've seen that there are several caveats with both approaches, and they're unofficial.

On the other hand, Sentry supports KMM officially, so I wonder if that will be more robust?

I've also seen that Bugsnag has official support, but it's in beta and has just 2 stars on GitHub.

Thank you 🙂

[Mario]

cc @kpgalligan @Rick Clephas - would really appreciate a 2025 update on crash reporting ❤️ (or a high-level overview of the caveats). Many of the threads here get into technicalities or are old.

[François]

Sentry/Crashkios use the same implementation of nsexecptionkit, there are not a lot of solution

[Taush Sampley]

Kotlin’s typical Not-Enough-iOS-Devs problem… I hate supporting Apple as a company, but I do have iOS experience if Jetbrains is hiring 👀 although it doesn’t look their jobs board has anything for KMM iOS-focused positions: https://www.jetbrains.com/careers/jobs/

[François]

The kotlin native stacktrace of an error is not perfect and sometimes hard to read, especially with coroutines, but it helps a little bit to find the cause of a crash.

[Rick Clephas]

but I’ve seen that there are several caveats with both approaches

To what caveats are you referring?

and they’re unofficial.

Correct, both libraries make it easier to integrate native crash reporting tools into a KMP application.

You already mentioned the official libraries by Sentry and Bugsnag.
I can’t really speak on their current state, but in the end a first party library would indeed be preferable.

would really appreciate a 2025 update on crash reporting

It hasn’t changed too much. The short version is that Kotlin provides the required hooks and information, but most native crash reporting tools can’t handle Kotlin crashes out-of-the-box.
First party libraries such as those from Sentry and Bugsnag should solve that (Crashlytics currently doesn’t have any).

In the meantime projects like NSExceptionKt and CrashKiOS make it easier to integrate the existing native libraries.

Some notes about the scope of these projects:
• NSExceptionKt only focuses on the Kotlin crash reporting through native libraries
• CrashKiOS also exposes additional API’s to Kotlin that allow you to log additional info
• Official libraries, like those from Sentry and Bugsnag, are much bigger in scope and aim to provide the full native library APIs in common Kotlin code

[Rick Clephas]

Kotlin’s typical Not-Enough-iOS-Devs problem…

IMO this isn’t a Kotlin/JetBrains problem. They are doing a great job at creating the Kotlin language including the native interop.
The whole idea of the language is to be interoperable, not to provide us with a full (mobile) multiplatform framework.

It’s up to us as a community to provide different solutions and ways to further integrate the Kotlin language in our projects and tools.
If you are looking to solve any of these problems you can create your own library or contribute to an official one to further improve the ecosystem.

[kpgalligan]

My quick statement on caveats. NSExceptionKt has a significantly simpler integration process, but the reason that works is because of the way the library avoids linker issues. @Rick Clephas found a way to integrate native libraries without needing to deal with those linker issues. I think it's rather clever, and it's a thing I'll keep in mind for any future native integrations. I didn't know it was possible. If I understand it correctly (entirely possible I don't) the KMP never directly calls the linked code itself, so the Kotlin compiler and various build flavors never demand that the symbols are available. The downside is that 'NSExceptionKt' can only provide the real crash data. You can't call methods to add breadcrumbs, associate data with a report or user, etc.
CrashKiOS used to implement an equivalent system to 'NSExceptionKt' for the actual stack building, but the implementation in 'NSExceptionKt' is great, so we decided to scrap ours and use the one from 'NSExceptionKt'. Work smarter, not harder, as they say. 'CrashKiOS' provides a more complete implementation of the underlying tools in that you can call methods to add breadcrumbs (logs, basically), associated data, etc. But, to do that, we need to satisfy the native linker. That's a huge can of worms.
Sentry essentially is the same situation. If you read the docs, if you're using SPM, you need to use CocoaPods and SPM to make the native definitions available for compiling and testing. I very much do think JB needs to figure out a better answer to the linking problem. It will only increase in urgency with CMP. There is a community effort to do that, which escapes me at the moment, but I will come back and edit this post if I remember. I have not tested it at all, so I don't know how well it works, but a way to link dependencies with SPM and without CocoaPods is an urgent need (IMHO).
As far as "official", I mean, sure. An official library feels more "real", but I'd argue KMP is a special situation. There are many first-class-yet-unofficial libraries that are providing a lot of the glue that allows the whole ecosystem to move forward. Then it's a slow grind to convince the 1st party folks to provide support directly (as in the case of Sentry). I don't think we're getting "official" support for the others in the near term, but as the community grows, it'll happen.
Anyway. If you just want crashes with proper Kotlin symbolication, I'd actually recommend 'NSExceptionKt' over 'CrashKiOS', because the config is simpler. If you want to write logs to Crashlytics from common code, then 'CrashKiOS', but make sure to pay attention to the linking docs. It's not a great situation.
Sentry is a perfectly functional implementation for that platform. We've desperately tried to avoid requiring CocoaPods for linking, which is what they use, but our various approaches for 'CrashKiOS' have resulted in other unforeseen complications. The way Sentry uses CocoaPods isn't bad. It's the implications. iOS team members will likely push back with "we don't use CocoaPods", but in this case, CocoaPods is only used for linking and the Kotlin compiler. That distinction can be difficult to explain. Also, if you're building locally, that means you need to install CocoaPods, which means installing Ruby, which means a version manager because the stock Ruby is old (yada yada)...

[kpgalligan]

To summarize the 3rd party native linking situation with KMP:

https://www.youtube.com/watch?v=Db_qXKBle08▾

[Giancarlo Buenaflor]

CocoaPods is only used for linking and the Kotlin compiler

fwiw we've added the Sentry KMP Gradle Plugin a while ago that sets up the linker with the Sentry SPM dep without cocoapods

[François]

Cocoapods is not require for sentry KMP.

[Taush Sampley]

IMO this isn’t a Kotlin/JetBrains problem.

Oh, absolutely not. It’s definitely a Kotlin/Community problem. Which I am trying to resolve independently, but it sure would be nice to get paid after being laid off :|

[kpgalligan]

fwiw we've added the Sentry KMP Gradle Plugin a while ago that sets up the linker with the Sentry SPM dep without cocoapods

Interesting! I've been out of the loop on Sentry's library I guess. Curious to see how it works. On the overall problem, though, SPM dependency support is something that's desperately needed to happen for some time. However it arrives.

[François]

@kpgalligan that my job with the spmforkmp plugin 😆