Sep 26, 2012

Using Crittercism SDK to effectively find & fix crashes

This post is talking about iOS apps, but I'm sure most of it applies to Android as well...

Having a crash report framework for your app is not really optional.

While investing in the QA phase before submitting your app can find and eliminate a lot of the crashes, there will always be something you'll miss, and there's nothing like millions of potential users to help you find and fix these annoying crashes when they happen.

Crittercism is a great example of a framework that makes sure you are going to get all the needed data from your users, AND may also be very helpful during the development & QA phase (in case you are not connected with a debugger and an exception breakpoint and a crash occurred).

The framework is really simple to use and the documentation is very succinct, so I'm not going to elaborate too much about the basic integration and features (such as symbolicated stack traces for each crash), but I DO want to tell you about some of my favorite features in the framework, that got us at JoyTunes to choose and use it for our iOS apps.

1. Live Data

This is a feature that is actually useful for app analytics regardless of crash monitoring, and it behaves much better than similar features in many analytics frameworks do.

You get live stats of how many app loads and how many of them crashed (filterable by app version).
This is cool because you can use it for live monitoring of app loads when an event occurs like a broadcast push notification.

In the same category, it's worth mentioning that new crashes appear in the list (and you get an e-mail) immediately as they happen. Especially useful for the QA phase when you don't have to wait hours to view the stack trace of a crash.

2. Crash Trends

Another great app analytics related feature. You can watch graphs of your DAU, MAU, App Loads, etc.
The most useful graph is the % of app loads that crashed, with separates graphs per app version.
This is really useful to make sure that you lowered the percentage by fixing crashes in certain versions, and make sure the new features you added didn't raise the percentage...

3. Breadcrumbs

While often looking at the stack trace alone is enough to understand what is going on and why the crash happened, there will be times you will find yourself staring at the stack trace not getting what were the circumstances that caused this line to crash.

This is where breadcrumbs kick in.

Using breadcrumbs effectively will let you track problematic user paths that may reproduce a crash in your development environment.

Since we are using Flurry for advanced analytics features, we simply added a method that reports an event both to Flurry and to Crittercism as a breadcrumb, and then we call this method instead of directly calling to the Flurry API.
This way each new flurry event is automatically reported as a breadcrumb as well.

The only caveat here is that while flurry supports parameters, Crittercism does not, so if parameters are important for you to understand what the user was doing, you should simply append the relevant info to the event's name when sending a breadcrumb.

4. User Metadata

By default, Crittercism creates a guest profile for each user of your app, and lets you know what crashes are affecting the same user.

This is useful by itself, but with User Metadata you get much more!

You can assign a username, an e-mail, and every other piece of metadata to a Crittercism user, and then you can link crashes analytics to each

This is useful for many things. For instance:

- If you get a support ticket with a description of a crash, you can "Search by User" in Crittercism and get all the info about the crash the ticket is referring to.

- If breadcrumbs data was not enough to identify the problem, and you want to further investigate the user's usage in your database/in other frameworks, you can do it by the username.

- You can contact all the users that suffered from a crash and let them know of a workaround or an app update that solves it.

- You can set up custom metadata fields to help you identify crashes that occur only to specific types of users (like the Diagnostics tab in a crash page helps you identify crashes that occur only for specific device types or iOS versions...)

That's it for this post.
Crittercism has a lot to offer besides the features I mentioned, like an in-app support forum, so you should definitely check out their website and see everything for yourselves.

But bottom line - I think Crittercism is a great affordable framework for monitoring and fixing crashes, and you should definitely consider it for any of your apps - just make sure you make the most out of it!


  1. Hi! I really enjoyed your post. I am hoping to use crittercism for a project I am working on but I don't want to lose flurry. Did you have to turn off some kind of setting for flurry crash reporting so the crash gets sent to crittercism?

  2. Thanks for sharing useful information for us. which provided me the required information about the latest Oracle financials online classes,we provide low price of fee for on-line coaching.
    Oracle fusion financials training