Analyzing Crashes - Mobile Dev Group Munich

Analyzing Crashes

That occur after Release

Agenda

• Why & What• Live Demo• General Advices

Problem

1. Crash2. If you are lucky: Reopen + Crash3. User Reactions:

Result

• Only 16% Will Try A Failing App More Than Twice (source: techcrunch.com)

• Bad Ratings / Poor Feedback

What causes a Crash?

• Location / Network / Weather• Hardware• Coding „Mistakes“• The User

Coding

• Nobody‘s Perfect• Lack of Testing (TDD, Device Tests, User Tests,

Crowd Tests)• Over Engineering

The User

• You Know how to use the App, because you Programm it!

• The User doesn‘t• Do not Trust User Input...

User Types: The Kid

User Types: The Dumb

User Types: The Troll

User Types: The „Hacker“

User Types

• The Dumb:– Improve UX

• The Hacker & The Troll:– Fix Security Issues

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

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/)

Live Demo

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!

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

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!