Collect issues that occur only in SDK using Sentry

[tobitech]

Hello! I'm using Sentry Cocoa in a Swift Package.
When I install the package in an iOS application that also uses Sentry with different DSN and force a manual test crash, the crashes are reported on the dashboard for the iOS application but not on the SDK Sentry dashboard
What I'm trying to achieve is that the Sentry setup inside the SDK reports issues/crashes that occur inside the SDK source code on the SDK Sentry dashboard and also shouldn't report crashes from host projects.

[philprime]

Hi @tobitech, thanks for asking.

Here's an excerpt from our documentation, explaining why it is discouraged to include Sentry in a third-party SDK:

It's considered bad practice to use Sentry SDKs in third-party plugins, packages, and libraries (such as payment SDKs or embeddable widgets) meant to be consumed by other apps. If an app uses a Sentry SDK in addition to a third-party package with its own Sentry SDK installed, the following issues can occur:

• Version conflicts.
• Signal handlers may overwrite each other, leading to one of the Sentry SDKs operating incorrectly.
• Third-party SDKs and libraries may leak users' PII data to the third-party's Sentry organization.

In addition to the aforementioned issues the SDK is designed to be running as a single static instance with a globally shared scope. Therefore, having multiple instances of the SDK running can cause interferences between them, causing issues for you and the app developers using your SDK.

[tobitech]

Hello @philprime Thanks for taking the time.
After digging through several discussions/issues on GitHub, I'm considering setting up a SentryHub with a SentryClient to capture errors in the SDK as opposed to using the global shared instance.
I don't mind having to manually capture errors at different points in the SDK (e.g. inside catch blocks) only that the setup might not automatically capture general crashes/exceptions.

Are there any other downsides to this approach?
Also what other solutions would you recommend for capturing crashes/exceptions in an SDK without interfering with host applications?
Thank you.

[philprime]

While setting up an additional SentryHub/SentryClient could allow you to reduce the automatic integrations to minimum, there is still internal functionality which uses SentryDependencyContainer.sharedInstance, which is a global dependency container that could still interfere with the app SDK.

Furthermore, AFAIK, the Swift Package Manager does not support "peer dependencies" or multiple versions of the same package, which could lead to version conflicts down the road.

Maybe @philipphofmann or @brustolin can chime in here and give additional feedback on what options exist to capture crashes/exceptions in third-party SDKs.

[philipphofmann]

Are there any other downsides to this approach?

Yes, the ones we already mentioned above: interfering with other signal handlers of the hosting app and mostly PII. Capturing crashes as a third-party SDK is tricky. You also need dSYMs of all your hosting applications, otherwise, your stacktraces will be only memory addresses. If you own all the hosting apps, I would rather browse all of them in Sentry and look search manually for SDK crashes. If all your hosting apps are in the same Sentry organization, you could use Discover to search across all your projects. Otherwise, it will get complicated. Again, you would need to upload all the dSYMs of all your applications to this one Sentry project. Grouping will be a challenge. Your SDK frames are most likely marked as non in app. For this to work correctly, you would need to manually set grouping rules. And I'm sure there will be plenty of other challenges. We're not saying you can't do it, but we discourage it due to all the mentioned problems. We also don't provide an official solution or a guide for it because it's quite some work to get this right, which we don't prioritize right now.

Anyways, if you really would like to achieve this, you could even self-host Sentry and enable our internal SDK crash detection. This does basically what you want just for Sentry SDKs, and you would need to modify the code quite a bit. We might do that for all public third-party SDKs in the future. You would have to claim a SDK and you would get a Sentry project. But that's just a crazy idea, which we have no clue if and when to ship.