Mark your calendars and get ready: On May 4, Fabric is being deprecated and folded into Firebase. We’re sorry to see it go but we also want to set developers up for success in a world without Crashlytics.
You’ve used the tool yourself so you already know the benefits. But remember, this time naturally allows you the space in your release cycle to wonder: What would life be like without Crashlytics? Can you do better if you were to make a switch in tooling?
Considering Crashlytics’ integration and subsequent increase in SDK size, it’s a great time for you to evaluate the cost-effectiveness of Crashlytics: Is using it as your dedicated crash reporter worth you having to search for other tools that handle logging, network monitoring, and more?
If the answer is yes, then Crashlytics will continue to be a great tool for you, especially if your sole focus is on crashes.
But have you stopped and asked your team yet how many times Crashlytics has helped you solve a crash in reality?
Again, you have to remember though that mobile analytics is capable of so much more than that: Not all crashes can be solved through stack trace dumps and a low number of crashes doesn’t necessarily mean your app is entirely stable.
- Incomplete Reporting: Crashlytics does not delineate between Android ANRs and crashes.
- Heavy SDK Load: Implementing Crashlytics forces developers to use other Google-backed products, adding to the size of your app. Developers could even find that this doubles their application size. Traditionally, teams have not found Google’s logging solution helpful, and many developers only want Crashlytics. When Fabric integrates into Firebase, this might get worse.
- Poor Retry Logic: In areas of low connectivity, Crashlytics can retry their request 4 - 5 times in a second, slowing down already sluggish user experiences.
If Crashlytics isn’t truly a tool for you to use as a developer, one that saves time and enhances your debugging capabilities, then it’s time to let it go and search the market for other mobile analytics tools that can provide more context to your team of mobile experts.
- Your next tool should give you full context. Crashlytics is solely a crash reporter; other tools can give you mobile monitoring and developer analytics, providing a holistic view all for a lesser SDK load.
- The tool should allow you to look at every user session. It should not merely provide sampled metrics. A user session involves logging, network calls and monitoring, crashes, and more, so that should all be rolled into one place, both for convenience and better understanding of the timeline your user experienced.
- The UI should be beautiful and simple—something your devs want to live in. Alerting and built-in issue tracking should save you time and energy when searching for bugs.
For example, we’ve helped developers solve crashes where Crashlytics was surfacing empty stack traces on all threads:
This above stack trace actually misdirected developers dealing with the crash. Engineers at Embrace however were able to utilize our User Timeline, a feature of our dashboard that chronologically recreates user sessions from network calls and logs, to reproduce the crash and create a testing procedure.
Here’s what our engineers saw on our platform:
The stack trace situation is similar, but we also get to look at the user session in question.
Here, we get to see an abundance of network errors, a period of inactivity where the user backgrounded the app, and that the user recorded a video and attempted to upload it (more info here).
So if your tooling can’t do that—if it can’t help you dive deeper and get closer to code, really understanding your user’s pain points—how can you say it helps your team improve app stability?
Embrace is a one-stop shop for your application performance monitoring and error debugging needs. We know that every user session is different, and tracking down bugs is about finding the exact session they happened on. That’s why we store every single user session and allow you to access them.
After all, sometimes the only way to make sense of a crash is to see exactly what caused it.