Announcing crash reporting: why have breadcrumbs when you can have the whole loaf?

Capture has changed the game

Since we launched Capture a year and a half ago, we have continuously heard from customers that the product has fundamentally changed how they approach mobile observability. Recall that Capture couples local storage with a real-time control plane, allowing for extremely efficient extraction of on-demand insights, yielding 1000x the data when you need it, and none when you don’t. Customers have been using Capture to understand system behavior and fix bugs that previously were deemed impossible to understand, let alone fix.

... for these applications, customer experience, customer happiness, and ultimately conversion, is governed much more by non-crashing issues than crashing issues.

What type of issues have customers been root causing and fixing? Largely, everything other than crashes. Performance bottlenecks, soft locks, functionality issues, customer support, etc. The list goes on. It turns out that in mature mobile applications, a huge portion of sessions are crash free (> 99.99%). This means that for these applications, customer experience, customer happiness, and ultimately conversion, is governed much more by non-crashing issues than crashing issues. The tools that Capture provides including dynamic workflows, synthetic metrics, funnels, user journeys, and session replay allow non-crashing issues to be investigated and solved in a way that was previously impossible with existing tooling. Yet, we would never argue that crashes don’t matter. Crashes are something that every mobile developer understands and every mobile organization tracks. A bad crashing event needs to be alerted on and fixed quickly, lest the typical 99.99% crash free session metric become much worse. To date, Capture has ceded crash reporting to other tools and has taken an integration approach. However, this is sub-optimal on multiple levels:

1. Users want less tools, not more. Given that crash reporting is considered a (reasonable) requirement, users may decide that it’s hard to justify another tool on top that provides introspection and debugging capabilities for non-crashing issues, even if that tool would materially improve customer experience and conversion on a broad scale.
2. The lack of first party crash reporting within Capture has hindered our ability to help users solve the rare, but still real, very tricky crashes where the stack trace alone does not lead to an obvious solution. For these crashes, users today typically rely on a very limited set of “breadcrumbs.” However, the Capture ring buffer renders industry standard breadcrumbs obsolete. We can provide vastly more information on all of the events that lead up to a crash, making it substantially easier to debug and fix the truly tricky ones.

The Capture ring buffer renders industry standard breadcrumbs obsolete. We can provide vastly more information on all of the events that lead up to a crash, making it substantially easier to debug and fix the truly tricky ones.

The suboptimal duality of a crash reporting solution plus a sophisticated RUM/generic observability solution ends today.

The addition of crash reporting

Today we are launching first party crash reporting support in Capture, which means that an additional crash reporting tool is no longer needed. At launch we will support:

1. iOS and iPadOS 15+
2. Android JVM on Android 5+
3. Android ANR on Android 11+
4. Android NDK on Android 12+ (coming soon)

Each crash report will contain the entirety of the dumped ring buffer (including session replay and performance resource utilization info) and be grouped into aggregate issues which can be used for triage and alerting.

What does this mean for users of Capture in practice? Capture is now a one stop shop for all things mobile observability. We have you covered for crashes, which at steady state are likely to be relevant to 0.01% of sessions or less. When crashes do happen, the ring buffer provides vastly more information to debug and fix the issue compared to industry standard breadcrumbs. As we said in the title, why have breadcrumbs when you can have the whole loaf? And for the 99.99% of sessions that are crash free, Capture’s local storage and control plane driven observability provides vastly better introspection capabilities than any other industry solution.

Crash reporting is part of a bigger picture

Historically, mobile observability was crash reporting. This is primarily due to the fact that mobile observability beyond crash reporting is very, very difficult. Over the last several years, all industry crash reporting solutions have moved into the higher level mobile observability space, but are architecturally constrained by the fact that they must send all data to the backend for processing. This is not only cost inefficient, but on mobile has significant implications for overall device data usage, which counterintuitively can actually decrease primary application performance by stealing precious bandwidth from the application itself. Capture started by attempting to solve the much larger, and we would argue much more important, general mobile observability problem, allowing users to dig into countless problems that affect the 99.99% of crash free sessions. First‑party crash reporting now rounds out Capture, placing this vital yet minor facet of mobile observability entirely within the product. While this launch is crash reporting table stakes, we have an aggressive roadmap planned for the rest of the year which includes:

• iOS app hang / UI unresponsiveness reporting
• More sophisticated issue grouping and triage capabilities
• Android ANR and NDK crashes on all Android OS versions
• And much more

Ultimately, our goal with bitdrift Capture is to help measurably improve overall end-user experience, leading to greater customer happiness and ultimately greater conversion. While we believe that most often doing this requires tackling non-crashing issues, a holistic solution that encompasses crashes is absolutely required and now Capture is a one-stop shop for all mobile observability needs. We could not be more excited to ship this and continue our quest to move the mobile industry quality bar higher and higher.

Come and get it

Capture is changing the mobile observability game by adding a control plane and local storage on every mobile device, providing extremely detailed telemetry when you need it, and none when you don’t. If lack of crash reporting was keeping you away, now is the time to give us a try! Interested in learning more? Check out the sandbox to get a hands-on feel for what working with Capture is like and then get in touch with us for a demo. Please join us in Slack as well to ask questions and give feedback!