Are watchdog timeout terminations a crash or not?

If an iOS app gets terminated by watchdog due to, for example, hanging the main thread, is that considered to be a crash or something different.

I'm asking because, according to google and AI, Crashlytics can detect and report these,but in my experience it does not. If I deliberately cause a watchdog termination by for example sleeping on the main thread for a long time then these never appear in Crashlytics.

I know Apple folks here don't comment on non Apple software, so I'm not asking about Crashlytics, just wondering and interested about watchdog timeout terminations and how they differ from a "regular" crash.

In normal discussion, it's common to describe watchdog terminations as crashes, since the customer experience of the app disappearing from the screen is the same, and both crashes and system terminations result in Apple crash reports for diagnostic purposes. But, there's a bunch of subtly to the details once you drill in beyond the common discussion phrasing.

For the sake of discussion, let's define a crash as things like bad memory access, uncaught exceptions, and the like — unexpected program conditions or logical errors in the app, and the crash is triggered by the app's running code from within its process. What I'm not including in that list are terminations where the system is observing the app through a system external to the app process (such as the watchdog). It is this external observer that terminates the app from outside the app process when a set of conditions is no longer satisfied, like UI responsiveness.

Apple uses the Mach exception and signal combination EXC_CRASH (SIGKILL) for most terminations‡. A variety of other combinations are used for crashes, such as EXC_BAD_ACCESS (SIGSEGV) as just one example of the many that are documented.

While I won't speak to the implementation of your specific crash reporting libraries, many crash reporting libraries historically rely on low level signal handling interfaces, where code can intercept a signal like SIGSEGV. That technique has significant drawbacks and we do not encourage it, with the rationale described in-depth over in Implementing Your Own Crash Reporter. In addition to the details shared there, there's one more mentioned on the signal man page‡‡, which says:

Except for the SIGKILL and SIGSTOP signals, the signal() function allows for a signal to be caught, to be ignored, or to generate an interrupt.

If a crash reporter happens to use signal handling to intercept a crash to do their work, they cannot catch SIGKILL. Thus, using my prior definition, such as technique could catch crashes like those having the SIGSEGV signal, but not terminations because those use the SIGKILL signal.

While signal handling were the way that crash reporters historically work, Apple offers MetricKit as a way to get app diagnostics, and salient to this discussion are classes like MXAppResponsivenessMetric, MXHangDiagnostic, and MXCrashDiagnostic. While I can't speak to your specific vendors, a crash reporter that uses those interfaces could get you information about when your app UI isn't responsive to help you improve your app.

— Ed Ford,  DTS Engineer

‡ We also use EXC_CRASH (SIGQUIT) in one scenario regarding keyboard app launch times.

‡‡ You can read this man page by running man signal in Terminal.

Are watchdog timeout terminations a crash or not?
 
 
Q