I’m looking to implement Sentry in my KMM project ...

# multiplatform

[Matti MK]

I’m looking to implement Sentry in my KMM project (Android & iOS targets), but from what I can gather by Googling and searching this channel is that Sentry support is not very mature. Some resources I found:

KMM implementation
• Experimental Sentry SDK for Kotlin Multiplatform, this apparently allows adding sentry to KMM shared module, instead of native implementations
Native implementation
• Add Sentry to native projects
• Kermit’s experimental Sentry support
• NSExceptionKt for Sentry, experimental
Has anyone successfully implemented Sentry in a KMM project and how did you approach the implementation?

[Seb Jachec]

We migrated from Firebase Crashlytics to Sentry in our KMM project just the other week, but used the separate native SDKs rather than the KMM SDK. I’m going to look at using NSExceptionKt next, but we’ve already found Sentry to be very useful (particularly w/ the Jetpack Compose navigation integration adding ‘breadcrumbs’).

When the KMM SDK is more mature, we’ll likely move over, but when I looked it was missing a few features we needed for our project (like explicitly setting an environment & release in the configuration options; being able to define a ‘beforeBreadcrumb’ callback [which I can see was just added yesterday]; or being able to set the current user), and besides that it’s not published to Maven so would have to be published locally

[Matti MK]

Thanks for the feedback 👍

That was what I was assuming as well

[kpgalligan]

Sentry is tough. We don’t use it, and the Kermit Sentry support is a contribution from somebody else, which means we’ve had less focus on it internally. Bugsnag and Crashlytics are far better supported currently. Kermit and NSExceptionKt are going to have some sort of a merge as NSExceptionKt gets the reports into one merged version. We had a solution for Bugsnag in the works, but it was more complicated 🙂 Anyway, the long term plan for all of these was to do “good enough” until the vendors implemented first party solutions. I had assumed that would be Bugsnag, as they’ve written blog posts on KMP going back a few years, but it looks like Sentry is first. We’re going to move Kermit’s implementation to just using that to log rather than implementing anything on top of it.

[kpgalligan]

Currently, if you configure things correctly, Bugsnag probably has the best crash reporting for anything coming out of the native side of Kotlin. Crashlytics is a sort of close 2nd. I occasionally chat with some people close to that team, but as the Android team starts adding more KMP to public Android code, it may be time to go back and bug them.

[kpgalligan]

At this point, though, I’d skip using Kermit’s Sentry implementation. We’ve had multiple reports of issues. Minor, but annoying. Once we get into September (Droidcon NYC and other things are pretty much occupying our excess time), we’ll get serious about replacing that.

[Matti MK]

Great, thanks for the feedback 👍

I’m on the same boat where I’m just looking for something good enough while waiting for Sentry’s first party implementation.

Going with native implementations and something lightweight enough (NSExceptionKt) to have the KMM side at least readable will work for now.

[kpgalligan]

I haven’t tried NSExceptionKt for Sentry, but I would imagine that’s a better bet.

[Matti MK]

I’m planning on a short medium article about the implementation and results once I’m done with this, so we’ll see. I’ll post it to this thread.

[kpgalligan]

The “problem” for Crashlytics and Bugsnag is, I think, since they’re in a single report now, first party support isn’t going to add a whole lot, so I wouldn’t expect much urgency, but then again, if there’s no problem, that’s not a problem 🙂

[Rick Clephas]

Some info (based on the development of NSExceptionKt) from the iOS/native side.

At the moment Bugsnag provides the best support for Kotlin crashes (or exceptions actually).
With their latest release all required APIs are public as well!
You can get a single crash report with support for caused by exceptions.

Sentry is indeed working on an official SDK for KMM.
With the Cocoa SDK it’s currently possible to log crashes as a single report (with caused by exceptions). But the code for that isn’t pretty, requires quite some private APIs.
That’s also why the Sentry implementation of NSExceptionKt is really experimental.

Crashlytics is lacking support for caused by exceptions. Which you can solve in a number of ways (e.g. merge stacktraces, 2 repots, etc). Besides that the only concern could be use of a small number of private APIs.

Issues for better K/N support:
• https://github.com/firebase/firebase-ios-sdk/issues/10030
• https://github.com/getsentry/sentry-cocoa/issues/1999

[Matti MK]

Finally got to the NSExceptionKt part of things!

After bumping everything up to support 1.7.10 I ran into the following issue trying to build the iOS target. Everything should be good, based on a look at your sample code, so I’m not quite sure where it’s going wrong.

Undefined symbols for architecture x86_64:
  "_OBJC_CLASS_$_SentryMechanism", referenced from:
      objc-class-ref in result.o
  "_OBJC_CLASS_$_SentryDependencyContainer", referenced from:
      objc-class-ref in result.o
  "_OBJC_CLASS_$_SentryEvent", referenced from:
      objc-class-ref in result.o
  "_OBJC_CLASS_$_SentryEnvelope", referenced from:
      objc-class-ref in result.o
  "_OBJC_CLASS_$_SentrySDK", referenced from:
      objc-class-ref in result.o
  "_OBJC_CLASS_$_SentryEnvelopeHeader", referenced from:
      objc-class-ref in result.o
  "_OBJC_CLASS_$_SentryEnvelopeItem", referenced from:
      objc-class-ref in result.o
  "_sentrycrash_async_backtrace_decref", referenced from:
      _Sentry_NSExceptionKt_SentryCrashStackCursorCleanup_wrapper5 in result.o
  "_OBJC_CLASS_$_SentryException", referenced from:
      objc-class-ref in result.o
  "_sentrycrashsc_initWithBacktrace", referenced from:
      _NSExceptionKt_SentryCrashStackCursorFromNSException in result.o
ld: symbol(s) not found for architecture x86_64

> Task :shared:linkPodDebugFrameworkIosX64 FAILED

Same issue for arm64 target.

[kpgalligan]

You need to build a static framework, then make sure sentry is in your iOS build.