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.