If you are a budding mobile (iOS or Android) developer, this could be a good place to start with your first release, but if you are a seasoned veteran, maybe this can widen your knowledge or even show you a few new ways worth trying.
If you let a version of your app out of your hand, you will know nothing about it – just bad reviews in the AppStore or on Google Play, but not a single detail you can rely on. This makes crashlogs a must have kit. I recommend you add crashlogs not only to the release versions of your app, but before the first alpha tests.
Your tests will transform into a meaningful report, not just “Something went wrong here and here…”.
Previously, there was one catch-all solution for crash reports, BugSense. But now there are far more, some are even integrated into beta test systems, like Fabric and many others.
Universal solutions for Mobile Developers
Splunk Mint (previously Bugsense)
Splunk is known for its Big Data handling solutions, and Mint is a little part of it.
Splunk Mint is a widely used solution, it supports Android, iOS, Windows Phone and others. It is easy to use:
- just create an account on https://mint.splunk.com, and
- create an app too, which will provide you an unique key.
- Once you have this key add your sdk to your project on Android (most preferred is gradle), or on iOS (with pods), but Bitcode should be disabled to get symbolicated reports.
- When the sdk is added, initialize Splunk during your app start in Application onCreate, or in AppDelegate with only one line.
Now you have a fully working crash report system, with a lot of info on your app.
There is a lot more to this library though, it provides analytics too:
- execution time measurements,
- event logs,
- activity monitoring,
- adding userData to your logs,
- and even breadcumbs, to help reproduce the crashes, shortening the fix times.
Splunk gives more than enough information, and a good and transparent website to manage them, you can also integrate Splunk into other tools, like JIRA, GitHub or HipChat.
Fabric (previously Crashlytics)
If you need a beta distribution system combined with crash reports, Fabric is a good a choice. Fabric has a plugin for Android Studio, and an app for OSX to manage the integration with a simple wizard-like flow. Fabric uploads the dSYM files to your iOS project automatically, this is essential for resymbolicating the crash reports, without it your logs will contain only memory addresses. Fabric can be integrated into other tools like JIRA, GitHub, Asana, HipChat and so on.
One of the key features of Fabric is its ability of taking the frequency of the crash into account, with which you can list (and fix) the crashes by importance.
Fabric gives you a fancy summary of your app’s events, with more than enough information about the devices as well. You can also close crash issues. You are able to add custom data to logs, userID, email, name, and key-value pairs.
Bitcode is also supported in Fabric.
Fanciness however sometimes affects usability negatively.
HockeyApp is similar to Fabric, it provides a beta distribution system, and crash reports, too. It has a built in update manager for beta distributions, offering the update within the application, rather than just with an email or with another app.
You can add additional data to your logs, and user data, too.
HockeyApp’s website is quite good, unlike on Fabric’s, everything can be searched and found. Plus, the HockeyApp website also has desktop and mobile apps for managing purposes.
Flurry is another combined monster, it provides crash reports and even an advertisement lib for the main mobile platforms. There is an easy implementation guide and samples too for Android, and both iOS – Objective-C and iOS – Swift.
It can log events with parameters and durations. Its serious drawback is that it’s not realtime: you should allow a day after putting it in your app to see whether it worked.
Instabug works almost the same way as any other crash reporter system. It delivers info, and you can link it to your developer tools like JIRA and Confluence.
The magic starts with a single line initialization.
With this one line you don’t just get a crash reporter, you get a really good feedback system. Testers just shake their device and they can send messages regarding bugs, requests or anything else in an entertaining dialog.
Shake it on a specific layout and draw on its screenshot, leave messages, images or voice notes, along with your email address.
On Instabug’s dashboard, developers get a message and they can prioritize it or start a conversation about it. This conversation is like a chat with emails, and the tester gets a notification about it, and can open a dialog from it. It is really funny and can improve the number and quality of reports.
One more thing on Instabug’s side, developers get long stacktraces, usersteps (lifecycle events), and custom userdata too.
Just a little preview:
Only for Android Developers
Now application stores would like to be a swiss penknife, be good for everything, therefore there are crashreports in Google Play too.
Google Play provides the most important pieces of information about a crash, including stacktrace, Android version, app version etc. It is a good way to start.
But crash reports will only be tracked if the user taps on the report button of a Force Close dialog, otherwise Google Play won’t be notified.
It is a built in function, but an Android developer cannot rely on it alone.
ACRA is a really complex crash report system. Its purpose is to make the Android developers’ work easier. You can provide your backend’s url, email or a lot more versions to ACRA and it will forward crashlogs to them. ACRA has an official backend solution, Acralyzer, but it is a little bit of an oldie. Fortunately you can use other alternative solutions, like HockeyApp or Splunk Mint, instead of the official one.
ACRA can even override the Android system behaviour, by replacing the Force Close dialogs with its own Toast, notifications or self dialogs with EditText to leave comments.
You can add custom data in key-value form, or even logcat info to your logs. Crashes are automatically cached if there is no internet connection during a crash, and upon the next startup they will be forwarded.
This library is nicely customisable, but cannot survive alone.
is free for under 500MB of daily data transfer.
It’s free up to 2 apps, above those you have 5 fix business options, 3 personal options, or unique offer (in yearly options, you have to pay for 10 months only).
Flurry is free.
It’s free up to 2 apps, above that you can purchase different plans with more and more features. Each plan contains 2 apps, but you can add extra apps for extra charges as well.
It is open source and free.
Splunk Mint’s reliable and really easy to use, so at Wanari, we use it in all applications that don’t require a special beta distribution system. In any other cases, we use Fabric, because it’s integrated into the system we use both on Windows and on OSX, plus it has a good beta distribution system to track the app states and logs, too.
Personally, I think Instabug is a really good approach, but it’s not cheap.
As a developer, you should definitely take a closer look and experiment with these tools, but I hope this list makes your life easier!
Latest posts by Gergely Szőke (see all)
- Replacing fragments with Conductors’ Controllers - May 25, 2017
- XML Drawables for Android Developers - April 12, 2017
- ZeroKit and Firebase Demo App First Look - March 9, 2017
- A Native Mobile Dev’s Favorite Libraries - July 20, 2016
- 7 Android Logging Tools Tested & Compared - June 29, 2016
- The Best Crash Report Tools for Android Developers - May 26, 2016