I switched from Flurry’s crash reporting to Crashlytics instead. Three main reasons.
1. Crashlytics is real-time processing data. If there’s a crash going on, you got it via e-mail and dashboard right away.
2. Crashlytics is able to extract and drill down to the lowest enough code level for you to easily track down the issues without a need to manually uploading desym file (but see the info below as well).
3. Web UI of Crashlytics attract you to work on resolving issues occurred. Open / Closed buttons is pretty darn sweet to click on.
I still have a curiosity about its build script, and desym file. I didn’t ask their support team just yet, but what I guess is below. If you have some thoughts about it, feel free to let me know.
I guess its build script would have to do something with the app/game ‘s build to extract desym information.
As I tested out, new build with strip debug info enabled is also processed fast, no need to wait for desym file to upload to its backend server, and I can see enough information to track down the issue in code-wise on their dashboard. With this quick, I bet that it doesn’t even upload desym file via its plugin program. So I thought the backend would communicate with its plugin program residing on the client system to get into desym file or debug information to symbolize things there and show on dashboard.