Can I use Embrace mobile monitoring at the same time as other exception handlers?

Most signal and exception handlers for iOS and Android are limited in the data they can provide mobile developers. For example, crash reporters can tell you when a coding failure has killed your Android app, but they can’t do a whole lot to tell you when an ANR is the root cause.

This inherent gap in exception handler data leads many developers to seek out tech that can provide supplemental data. Indeed, many Embrace customers found our technology while already using crash reporters like Instabug, Sentry, and Firebase.

While it’s absolutely possible and exceedingly common to string multiple exception handlers together in Android, it’s far more complicated to do the same on iOS. Worse, failure to carefully coordinate multiple exception handlers will more likely than not result in inaccurate data from one or more handlers.

What happens when I use multiple exception handlers?

If you’re considering adding a signal or exception handler to your tech stack, you’ll want to be aware of potential complications that can occur when, for example, you’re using two crash reporters at once.

In that regard, let’s consider this scenario for both Android and iOS.

Using multiple crash reporters in Android

Android’s Java Virtual Machine (JVM) makes it easy to chain exception handlers together with other third-party SDKs, as Android’s operating system will simply call one handler after the other. As a note, handlers that are chained together are called in the reverse order by which they are registered. That said, there are two main risks when using multiple exception handlers like this on Android: Triggering ANRs and producing outdated or misleading data down chain.

Since the Android JVM will call one exception handler after the other, this can lead to a scenario where too much work has been scheduled in the app, potentially causing an ANR, and ultimately crashing the app.

Additionally, the quality of the data you get out of your exception handler can depend on where it is placed in the chain of command. The first exception handler to be called will have the most accurate data, since it’s able to take a snapshot of the system state at the moment an exception occurred. While the original exception and stack trace should be passed along to subsequent handlers, those that find themselves down chain will ultimately take their snapshot at a slightly later time, potentially making any metadata provided, such as a timestamp, slightly outdated or misleading.

Similarly, if an exception handler contains bugs or is causing bad behavior, it can potentially alter the data captured by exception handlers further down the chain.

Using multiple crash reporters in iOS

iOS uses signal handlers, which are not chained to call one after the other. Therefore, whichever handler was installed last — and is therefore first in line to be called by the OS — will get the useful data.

There is an exception to this rule, however minor.

While signals don’t have a built-in mechanism to chain handlers together, it is possible for a handler to be a good citizen by:

• Saving the data it captures;
• Calling the next handler in line when it’s done processing the data it’s captured;
• And passing the originally captured data along to the next exception handler.

That said, this is a complex process and not at all standard within third-party SDKs. It’s a best-case scenario.

In most scenarios, the signal handler will do nothing to call the next handler in line, and therefore no data will be passed along. On rare occasions, an SDK will alter the signal and pass along inaccurate data.

This is the main reason many recommend using only a single crash reporter when developing apps for iOS in C, C++, Obj-C, and/or Swift: You’ll either receive no data, or misleading data due to conflicts between different handlers.

Using Embrace with other crash reporters and exception handlers

The Embrace SDK functions similarly to other crash reporters and exception handlers, and is therefore subject to the same risks as outlined above.

With that in mind, we strongly recommend against using Embrace in parallel with other signal handlers on iOS. If you’ve run into complications, a good first step for troubleshooting is to disable C/C++ crash reporting within the other SDKs which could be responsible. If complications persist, please contact your customer success manager or email support at support@embrace.io.

It’s also worth noting that these same risks apply to developers using signal handlers for C/C++ crashes in Android.

However, Android developers that are only interested in JVM crashes shouldn’t have a problem running Embrace in parallel with their other SDKs. They should, however, keep in mind the risks outlined above when analyzing discrepancies in data from multiple handlers. Questions about the data you’re seeing in the Embrace platform can always be sent to your customer success manager or to support@embrace.io.

Said more simply, our recommendations can be summed up as follows:

• On iOS, you’ll want to follow the best practice of only using a single crash reporter at a time.
• On Android, it’s okay to use multiple JVM crash reporters in a single app, but you’ll want to keep in mind the risks associated with missing data or triggering ANRs.
• When monitoring C/C++ crashes in either platform, you should always do so using one signal handler at a time.

If you’d like to see how complete mobile visibility with Embrace can revolutionize how you deliver incredible mobile experiences, get started with a free trial today.