How We Utilize Firebase Crashlytics To Improve Our Service

In a mission to help connecting #OrangBaik across Indonesia

A Little Story of Firebase Crashlytics

For those of you who don’t know what Crashlytics is, which I highly doubt that; it was an IT company based that helps developer collecting, analyzing, and organizing app crash reports. For mobile developers, it also helps us distributing the APK/IPA to the QA easier by using Fabric (which is now deprecated and moved into Firebase Crashlytics and App Distribution).

The original logo of Crashlytics and Fabric

It was acquired by Twitter in 2013 before taken by Google at January 2017. It was two years and half before Google announced Fabric deprecation and introduced Firebase Crashlytics. It’s now believed served more than a million developers around the world.

This is the appearance of Fabric Migration to Firebase

If you haven’t implemented this into your project, i suggest you to start it from now. Because we would never know what kind of crash, how to reproduce the error, and the specification device that users uses when our app crash. You can try it by yourself about setting it in the starter documentation.

Use Case

Based on our knowledge, we know that Firebase Crashlytics retrieves the logs whenever our application is crashed. It knows which version and the build number, which class that contains the error, and which exact line of code that produce the crash. It really helps developer to investigate the error, create hotfix and upload the final result to the appstore/playstore so it will make the user happy and stay connected to our app. But if you read more about Firebase Crashlytics, it also provides us to report the non fatal error from our app too. Now what exactly is the non fatal error? In my understanding, it is as an error but it doesn’t cause a crash to our app. Still don’t get it? OK. Here’s the example. So let’s say you have a method that calls an HTTP request and somehow the response always returns failed and we don’t know how to trace the error log. Even with the help of Backend team, your team still cannot trace the exact scenario and cannot reproduce the error too. As a result, we don’ t know how to solve the issue and the bad news is, the user keeps complaining about how bad your app is.

We’ve tried our best guys. Please hold on :)

That type of error is really annoying and that’s what i felt too. So, after doing some research with my team, we found that Firebase Crashlytics non fatal error and started to use it. And if you look into the documentation, the setup is really simple. For this scenario, i would give you a sample in iOS perspective. After setting up the Firebase and Firebase Crashlytics into your project, you can start to call a method that handles the non fatal error reporting.

Crashlytics.crashlytics().record(error: error)

Since the record(error:) only receives the type of NSError, you should initialise the log to be something like this

let userInfo: [String:Any] = [
  NSLocalizedDescriptionKey: "The request failed.",
  NSLocalizedFailureReasonErrorKey: "The response returned a 404.",
  NSLocalizedRecoverySuggestionErrorKey: "Does this page exist?",
  "ProductID": "123456",
  "View": "MainView",
]

let error: NSError = NSError(domain: NSCocoaErrorDomain,
                         code: -1001,
                         userInfo: userInfo)

You can customise the key and value inside of the userInfo. In my case, i fill the userInfo with the things that helps my Backend to trace the issue. And that’s it!

Now what happens is that, whenever it triggers the method, you can see the result in Firebase Dashboard -> Crashlytics. After that, you should filter the Event Type into non fatals and apply it. Please note that it may take 2–3 hours to see the result. Even in my case, i got to see the result in the next day.

Here’s the sample of the final result

Final Thought

Before we decided to use Firebase Crashlytics, we debated about the usage of it. We argued that this should be handled by the Backend team. But since our Backend has done enough and is still evolving, we finally decided that this is another solution that not only helps tracing the real scenario of how to reproduce the error, but also makes the Backend team easily tracing the culprit. It’s now integrated in some use cases to see the effectivity of this implementation.

Since you’ve reached at the bottom of this article, i would like to give you an information that we are also hiring. You can check it here

Have a great day! ;)