Our engineers recommend against doing so.
We don’t have proof that it definitely would cause problems or fail, but it can easily be haphazard and cause subtle behaviors that influence the behavior of the SDK, thereby not giving you an accurate picture of how to SDK and product works. It could also bring down your app altogether. You have now been warned.
Part of the reason behind this risk is that there are global error handling classes, and the framework has its own error handling classes as well, so if 2 SDK’s are both consuming from or watching what these classes are doing, it could create a race condition, or one sdk could block the other sdk, or both execute at once (same thread, or multiple threads) and cause problem, or cause some other unwanted behavior not described here. How these interactions work is not well understood, and that’s because it’s risky to attempt them in general and it’s not the intended or supported use case in general.
Here’s a quick look at how Sentry handles your personal information (PII).
×We collect PII about people browsing our website, users of the Sentry service, prospective customers, and people who otherwise interact with us.
What if my PII is included in data sent to Sentry by a Sentry customer (e.g., someone using Sentry to monitor their app)? In this case you have to contact the Sentry customer (e.g., the maker of the app). We do not control the data that is sent to us through the Sentry service for the purposes of application monitoring.
Am I included?We may disclose your PII to the following type of recipients:
You may have the following rights related to your PII:
If you have any questions or concerns about your privacy at Sentry, please email us at compliance@sentry.io.
If you are a California resident, see our Supplemental notice.