4

I've got a very basic, but terribly important and potentially impossible question: how does one go about diagnosing a bug you can't reproduce?

Twice now, I've gotten emails from people asking about app-crashing bugs that I can't reproduce. Non-modified iPhones, current software, tried reinstalling and hard resets, etc. It crashes every time for them, and it works perfectly for me, (not to mention it got approved for the App Store in the first place so I'm clearly not the only one). I had always understood that the consistency of the devices was one of Apple's big selling points for developers, but that also makes it hard to pinpoint what's different about their device from mine...

So, aside from "just keep testing," is there a trick-of-the-trade among programmers for this sort of thing? Some function of the iPhone simulator that lets you test not just different screen sizes but different hardware configurations, etc? Or am I just out of luck, and stuck telling my customer "sorry, it works for me"?

Can anyone share their experiences or suggestions about this?

rmaddy
  • 314,917
  • 42
  • 532
  • 579
Nerrolken
  • 1,975
  • 3
  • 24
  • 53
  • Get the crash reports from the user if you can. – rmaddy Aug 22 '13 at 20:27
  • Write perfect code? Look at your watch about 11:45pm, after a long day of debugging? (There's a war story behind that last one.) – Hot Licks Aug 22 '13 at 20:30
  • 2
    If your app repeatedly fails for a given customer (or customers in, say, a particular region of the world) then there is probably something unique about their setup that you need to understand -- simply trying and retrying randomly to reproduce won't do it. – Hot Licks Aug 22 '13 at 20:32
  • 1
    To expand on @HotLicks comment, I find it beneficial to determine the locale, date/times, input preferences, and accessibility settings a user is using. If it's a particular user's device crashing consistently that can sometimes hold the key. – Carl Veazey Aug 22 '13 at 20:33
  • 1
    For an example of a weird (sorta) regional thing that can bite you, see [this](http://stackoverflow.com/questions/6613110/what-is-the-best-way-to-deal-with-the-nsdateformatter-locale-feature). – Hot Licks Aug 22 '13 at 20:34
  • (But, unfortunately, there is a lot of device-to-device variation based on iOS level and device version. These are hard to suss out without actually having that device.) – Hot Licks Aug 22 '13 at 20:36

4 Answers4

3

You should probably start by installing a crash reporting tool like Crashlytics. This may give you the clues you need or at least help you narrow down where to put additional crash logging.

Timothy Moose
  • 9,895
  • 3
  • 33
  • 44
  • This ended up being the best solution for me. Crashlytics is awesome, I use it in every single one of my apps now. Highly recommended to anyone reading this, and thank you to Timothy Moose for the suggestion! – Nerrolken Oct 23 '13 at 21:07
3

While the iTunes Connect crash reports can be helpful, the crash reporting services like Crittercism are more user-friendly and full-featured. Crittercism has been very helpful in tracking down infrequently-occurring crashes for my apps and can be used no-charge. (I have no association with Crittercism.)

mjswan
  • 91
  • 4
2

In iTunes Connect you can access crash reports. These crash reports include call stacks that you can symbolicate and then you can see where it actually crashes.

Here is some good instructions for symbolicating: symbolicating-iphone-app-crash-reports

Community
  • 1
  • 1
www.jensolsson.se
  • 3,023
  • 2
  • 35
  • 65
2

It's important to keep your dsym files from each build & archive safe. You can use them to symbolicate crash reports, to see details of the crash. Users will have to opt in to submitting crash reports though. I think this is a feature of iTunesConnect.

Daddy
  • 9,045
  • 7
  • 69
  • 98