Flurry error reporting vs other error reporting services such as Crittercism & Crashlytics etc

Question

We are evaluating various error reporting services for iOS and Android apps. Our app uses webservices to connect to the server.

We currently use Flurry analytics but have not yet used their new error reporting feature.

What is your feedback on Flurry error reporting, if you are using that today?

I am trying to compare it with Crittercism and Crashlytics. So, if anyone out there have experience using Flurry error reporting and Crittercism or Crashlytics, it would be great to hear your feedback.

Thanks.

Answer 1

While this question is likely more suited for a forum, I'll do my best to answer your question from my experience with these technologies as well as what I've heard from others. First lets look at what these services provide for Crash Reporting, then lets look at what they provide that ties into Crash Reporting.

Flurry provides (at a high level):

• Analytics of event based metrics (this includes optional basic crash reporting)
• server-side symbolication (however uploading symbols is a manual process)

All this is great, but they really don't focus on crash reporting at all or how that ties into other metrics.

Crittercism provides (at a high level):

• real-time insights on reports (system diagnostics, logs, etc)
• smart crash/error grouping
• error monitoring with actionable diagnostic information
• logging non-volatile errors
• server-side symbolication for stack traces
• location correlation with above metrics
• session based metrics for a crash report
• client perspective network performance data (note: this would be great to keep track of your web services and other 3rd party services, such as Flurry, to see how they're performing)
• trends of above metrics and data
• connection between network calls and crash/error reports (look at breadcrumbs)

See the above link for more details on the full package that Crittercism provides. For more details on some of the features, check out this page.

All of these are focused on giving you full visibility on how your app is performing for each of your users.

Crashlytics provides (at a high level):

• smart crash/error grouping
• error monitoring with actionable diagnostic information
• server-side symbolication for stack traces
• logging non-volatile errors
• real-time insights on reports (system diagnostics, etc)

Flurry can be paired with more robust solutions for Crash Reporting and in my experience most end up taking this route.

Crittercism provides a lot more than just Crash Reporting that ties back to optimizing the performance of your applications with actionable data. They also hook into Mobile-ready support systems (such as UserVoice and HelpShift) for better customer communication, and several task management systems for engineering (JIRA, Github, Pivotal). Server-side symbolication, APIs to pull data, simple integration with build tools (such as Jenkins) provide a much more mature solution.

Crashlytics provides an easy integration for the average developer. I've heard complaints from developers with more defined build processes (such as something that uses Jenkins) that their app integration for uploading symbols for symbolication gets troublesome.

They also provide integrations with JIRA and Github. Not sure at what level.

Some love the UI for Crashlytics, whereas others have stated that it gets in the way.

Hope this helps.

Answer 2

I have been using Crashlytics pretty much since it first launched for Android and iOS. It's a pretty impressive system with some massive pros:

• Extremely lightweight library
• Compatible with major development environments
• Real time insights
• Crash grouping
• Individual crash breakdown
  • Tagged with user information
  • Custom keys/logging
• Email alerts
  • Impact level changes
  • New bugs
  • Daily summary reports
• User management for sharing access
• It's free

There is also a split between crashes and non-fatals which means you can report handled exceptions back without having the app crash. For example, in our Logging class we have this method which gets called when an exception could happen, but shouldn't. This means that we have a breakdown of how often this happens and we can work towards resolving it:

// Android
public static void log_wtf(Throwable throwable)
{
    Log.wtf("Log", throwable.toString());

    // Also log this exception to Crashlytics
    Crashlytics.logException(throwable);
}

I particularly like the crash breakdown which lets you see each individual crash report from a group of reports. You can ask the users to use their name, or do what we do and sign it with their login credentials for our service (see the user info on the right):

This is invaluable information for us which allows us to easily and quickly reproduce the error.

You also get a version breakdown which you can disable at a later point. For example, if we have just finished a test of alpha version 0.1 (1), you can turn logging off for that version and launch version 0.2 (2). If someone forgets to update their application you will not be notified of anything from that point. Obiviously this isn't good when your app is in production, but useful for testing phases.

While I haven't tested it they have integrations for other services including your own web hooks if you wish to develop something to support it. It's in my plans to do this to automatically create trac bug tickets, however I haven't got around to it yet!

Oh, and finally, let's not forget the sweet animations crashlytics employs throughout it's software.

Answer 3

I would recommend going with Crashlytics. They have the smoothest onboarding process of any error reporting software. It's very easy to setup and incredibly intuitive to use. The reporting is immediate and spot on. They also have the best console UI of the bunch. I've used them now at Evernote, HomeAway, and my own apps and I've never ran into any problems. They also have a great support team that responds very very quickly, normally within minutes to inquiries.

I've also used Flurry in the past, for event tracking, with mixed results. Their numbers always seemed to be a bit off. You also have to go through and add start/stop events in every activity which can be a pain.