Firebase Crash Reporting VS Crashlytics
Let the showdown begin
Firebase, Google’s latest platform, offers a comprehensive set of tools and services to help kickstarting the development of new apps and to accelerate the growth of existing ones.
One tool that particularly catches our interest as developers is Firebase Crash Reporting. Crash analysis is a core part of our daily tasks, and aims at solving problems that users experienced with our app by looking at the stack trace and, together with its context, fixing troublesome bugs and pesky conditions. For this reason, the crash reporting tool of choice has to offer a specific set of features in order for us to do a good job, and should also be as simple and immediate as possible (because let’s face it, developers are the ones that bitch the most about UX, and for a good reason).
Fabric’s Crashlytics has been the go-to solution for many years now, to the point of being a no brainer. But since Firebase Crash Reporting was announced, many developers started wondering if things have changed and whether they should move to Google’s omni-comprehensive solution.
This is exactly what this article is about, inspired by my question/answer on StackOverflow. We will highlight the differences that stand between these two tools, both from a technical and a usability point of view. We focus on Android, since it’s the platform I work on, but many considerations stand true for iOS as well.
DISCLAIMER: Firebase Crash Reporting is currently labeled as beta. This means that what we see is very likely to change during the upcoming weeks. Keep this in mind when considering which tool is the right one for you!
User Interface and User Experience
Let’s start with the oh-not-so-good, as this is probably the pain point of Firebase Crash Reporting (from now on, simply Firebase). While the user interface looks nice, it is very basic and yet lacks basic features for an online tool.
For instance, it does not remember how many items per page you want to see, ever: choose 50 items per page, click on a crash to see more info, go back and you’re back at 20 items per page. Argh, so annoying! Crashlytics, on the other hand, offers infinite scrolling, so this issue just isn’t there. And the lack of filters persistence across pages extends to every aspect: app version, error type, and so on and so forth.
Another big improvement that Firebase could borrow from its competitor is the ability of marking crashes as “resolved”: this is extremely helpful, because you see at a glance what’s left to address for that particular version.
Firebase: what’s there to like
Let’s get to the point here. You probably want to see a list of pros and cons, something quick and immediate that helps you decide what tool is the better one for you. And here it is, this is a list of what’s better with Firebase over Crashlytics.
- Both ordinary and native crashes are displayed in Firebase
- Automatically integrates with Firebase Analytics, which enables grouping users that experienced crashes into an audience
- Dead-easy setup (just include the Gradle module, possibly the google-services.json file), plus no singleton to initialize
- All-in-one console with other Firebase products (if you plan on using them)
- Lower number of methods (even though it includes Analytics, using the standard methods allows ProGuard to strip almost everything, so props to Google for that)
- Possible to turn off gathering analytics on a per-user basis
As you can see, there’s plenty to like. First and foremost, the seamless integration with Firebase Analytics allows you to create an “audience” of users that experienced troubles when using your app: you can then take actions in order to let them know that you’re aware of those issues (e.g., send a push notification, with Firebase Notifications!).
In addition, you no longer have to manually catch and log native crashes, or look them in the Google Play Developer Console: everything is in one place and collected automatically.
Firebase: what’s missing and what can be improved
The service is still in beta, so many features are being added/considered at the time being (see here for a list of known issues). However, if you need to make a decision now, here’s a list of things that I consider downsides when it comes to using Firebase over Crashlytics.
- Requires Google Play Services on the device (big requirement)
- Searching through crashes is not available
- Not possible to mark a crash as resolved
- ProGuard/DexGuard mapping files have to be uploaded manually (Google is on this)
- Impossible to have a listener in the session just after a crash occurred
The first point is a major one. Firebase will not work if Google Play Services are missing from the device, in which case you can say goodbye to your beloved crash reports (along with everything else in the Firebase suite). Depending on your app’s market location (China, anyone?), this can be a huge deal.
Another feature that often goes unnoticed, but really shows users that you care about their experience with your app, is the ability of registering a callback that is triggered the first time the user opens your app after a crash. You can, for example, show a nice dialog where you ask the user to send a feedback about what series of actions led to the crash.
Bottom line
There is no “best” service here, there only the service that better suits your needs. Firebase, for being beta, already accomplishes great tasks and is very powerful. Having a competitor like Crashlytics, which used to be the best in class on its category, only helps Firebase growing more and becoming more refined.
Unfortunately, most likely you won’t be able to add them both simultaneously and see what performs better or what you see more fit for your app, due to the nature of how crash reporting tools work (see UncaughtExceptionHandler, if you’re curious — EDIT: apparently, these two particular tools behave correctly in not blocking the exception, so you may very well use them both at the same time and see what performs better for you). Hopefully this article gave you something to work with when you have to make a decision, whether you’re starting fresh or you’re considering a switch.
