Mobile Dev Group Munich Talk

1. Analyzing Crashes
That occur after Release

2. Agenda
• Why & What
• Live Demo
• General Advices

3. Problem
1. Crash
2. If you are lucky: Reopen + Crash
3. User Reactions:

4. Result
• Only 16% Will Try A Failing App More Than
Twice (source: techcrunch.com)
• Bad Ratings / Poor Feedback

5. What causes a Crash?
• Location / Network / Weather
• Hardware
• Coding „Mistakes“
• The User

6. Coding
• Nobody‘s Perfect
• Lack of Testing (TDD, Device Tests, User
Tests, Crowd Tests)
• Over Engineering

7. The User
• You Know how to use the App, because you
Programm it!
• The User doesn‘t
• Do not Trust User Input...

8. User Types: The Kid

9. User Types: The Dumb

10. User Types: The Troll

11. User Types: The „Hacker“

12. User Types
• The Dumb:
– Improve UX
• The Hacker & The Troll:
– Fix Security Issues

13. Risk of Crash
• Level 1:
– Network Access
• Level 2:
– 3rd Party Software / SDK‘S
– Content you don‘t Create (e.G.: CMS)
– Legacy Device Support (e.G.: Android 2.3)
• Level 3:
– User Input

14. Popular Crash Frameworks
• Crashlytics (http://www.crashlytics.com/)
• Bugsense (https://www.bugsense.com)
• HockeyApp (http://hockeyapp.net/)
• TestFlight (http://testflightapp.com/)
• TestFairy (https://www.testfairy.com/)

15. Live Demo

16. Benefits
• iOS: usage of dwarfdump for reading crash
reports takes too much time plus has much
too do manual (example of the old way: nove
rse.com)
• Accumulated Statistics per Release Version
• Better General Overview
• Search functionality!

17. Some Advices:
• Log Custom Keys (Checkpoints)
• Send Caught Exceptions Aswell
• Log, and log it to the Service Aswell
– Pro Tip: use Timber
https://github.com/JakeWharton/timber

18. Thanks
Thanks for Listening!
https://plus.google.com/+AngeloRüggeberg/
https://www.xing.com/profile/Angelo_Rueggeberg
Want me to work for you? Hire Me!