A user is reporting a crash in my app but I can't seem to recreate it and have not heard of this crash from any other users. He claims the app crashes when he comes back to it after using different apps. There are no crash reports on iTunes connect either and hes using the latest device and os.
Have the user follow the directions here:
http://www.ispeeddial.com/how-to-find-the-crash-log-for-an-iphone-application/
You should not worried about it much. There are many SDk around which allow user to submit there bugs/feedback direct to developer rather than on itune store. There may be several reason either he/she put down your app(marketing strategy). But the nicer solution is i can tell you that somehow may depend of your code may be related the memory leak. If you are confident with your coding standard then finally you should not worry about until unless many people does not complain about it
I've had three users of an app I've published say that it crashes. I've run it in Instruments and there are no leaks and no over released objects either. I've been using the app myself quite a bit for at least 2 weeks and it doesn't crash for me.
I was wondering if anyone had any tips on how to problem solve an issue like this.
One thing that I'm suspicious of is the Millenial Media ads that I have running in some of the views. A Build and Analyze reveals 13 issues and they all pertain to the ad API
thanks for any help
The best way to figure out the cause of a crash is to get hold of the crash reports from the affected iPhones. Anything else will just be guesswork.
Either you might be able to have the users send you a crash report or you will have to sit it out until enough users are affected and it shows up in iTunesConnect. The last one is not really an option if you want to have a bugfix out quickly since there are several reports that says the you might need as much as over 100 crash reports before it actually shows up in iTunesConnect.
To solve this problem in the future (not going to do much for your current bug) is to install QuincyKit. It'll send you the crash reports directly from the affected iPhones the next time your app is launched. You can either have this as a hosted solution at HockeyApp or you can host this yourself for free. QuincyKit is available for download from GitHub.
The crash log returned when your app has an error on iOS is wonderful however it would be 100 times better if it contained the console output from when your app started as part of the log. Is there a way to automatically have that information in the crash log, or have a semi-automatic system that testers could use when sending in crash logs?
I think you might want to take a look at http://apphance.com. It's exactly what you are looking for - including capability of sending problem reports from device by testers, including screenshots, you can track history of session including full console logs, you can even see crashes from out-of-memory problems which are otherwise difficult to get without physical access to the device. It's closed beta for now but soon it will be open for everyone. You can request access directly at the page.
Disclaimer: I am CTO of Polidea, company which is behind apphance and co-creator of the service.
#Medran i am not sure if this will help but if you can get the Brad Larsons videos on Advance iPhone App Development than there he says some thing about .dSYM file that will help you find the places where crash occurs. .dSYM file is made when you build your app using Xcode. See if you can find that file in your project folder its named something like this MYapp.app.dSYM
Some say it doesnt start on their HTC Hero, another says it doesnt open in their Cliq, etc. I built the entire app using my Droid X to debug. Now that the app is released, and the code is interacting with so many different types of hardware, how do I figure out what may be going wrong for these users?
In my Crash errors log I have one record of a crash, and I believe I've already fixed this. It was certainly not responsible for the crashes that users are complaining about.
Maybe you have to check manually or maybe it's a problem of multiresolution because different mobile have different resolutions. Otherwise if it is possible then you have to include crash log report in your application which send crash logs to your email id.
Or you can ask them to install crash log reporter and set your emailid to target for crash report. Try this link, first one for manually adding code to your application.
https://github.com/tomquist/Android-Error-Reporter
http://www.androidzoom.com/android_applications/tools/log-collector_tlt.html
Do you have any Logcat outputs in release mode? May be they help you out..
Alternatively, you can test it out on 3rd party mobile testing vendors.. Where in you can buy some hours and do some quick testing...
After submitting our application several times, we continue to receive the following response:
Thank you for submitting My App to the
App Store. We've reviewed your
application and determined that we
cannot post this version of your iPad
application to the App Store because
My App is crashing on iPad running
iPhone OS 3.2 and Mac OS X 10.6.2. My
App crashes upon launch.
Unfortunately, crash logs have not
been generated.
However, resigning the same build with the AdHoc entitlements and loading the build onto the device yields no such crash. After a number of attempts, the application simply does not crash as reported by the reviewer. Furthermore, the reviewer does not provide any useful logging that may have been generated by SpringBoard such as an exit status or event if it had worked properly for any other device. There are no calls to explicitly exit or quit the application in the code line and yet the application terminates on startup.
What might cause an application to terminate in such a manner?
Under what conditions is an application tested that might not be found under a development environment?
Could it be a result of a signing issue that the submission validation system is simply unable to catch?
Thanks in advance.
After fighting with this for weeks, the application has finally been approved. The key: signing corruption. Hence why the application would start (or at least appear to start by showing the splash screen) and then suddenly vanish without a crash log. It failed Springboard's preflight sighing check.
A good tool to keep in mind to check for signing issues. It tells if the application has a valid signing:
codesign -vvvv MyApp.app
When I built the application, I would cp it to a network storage device where our product manager would pull it down and submit it to Apple. If decompressed on the NAS, the code signing was valid. But if you coped the compressed application back off the NAS and validate it, it would fail.
The lesson: make use of the new XCode utility to submit applications.
A few suggestions:
Try to use the leaks tool of the static analyzer to see if there are any memory leaks or problems your not seeing.
Does your app use a web service? This happened to me one time because the day Apple was reviewing the app the web service went down. That cause a crash. If thats the case you would want to add something to catch that.
Finally, In the logs Apple sent you did they send you the dsym file? If they did you can run atos from the command line and it will convert the address to symbols. That will show you what thread and symbol it's crashing on.
Be sure you test with a variety of settings: with Wifi disabled/enabled, with 3G disabled, Airplane mode on/off, location services disabled, etc.
As a last resort, assume there is a problem in your code that executes at startup. Remove half your startup code, set your release date in the far future (just in case it gets approved), then resubmit and see if they have the same problem. If not the problem is in the half you removed... it's a binary search.
I think you have two options: try harder to reproduce the defect using the tools other people are mentioning or to catch those crashes in the field.
PLCrashReporter will trap on an uncaught exception and store all relevant information. Next time your app is run, it can send the crash report that you can then symbolificate and view a stack trace of.
Ouch! That's a tough one. I've had this kind of thing happen before, but it seemed it was reproduce-able when I switched to a different device (iPhone 3G vs 3Gs, etc.). In your case though, it sounds like you're iPad only, so that might not help. There's a difference between 3G and Wifi, I suppose, but I would be really surprised if that was causing a crash on one and not the other.
One thing you could try if you think Apple's not doing their part is to change the binary name and re-submit it under another app name/record. See if you get the same response. If you get the same reviewer, you might, but I think there's a good chance you would get a different reviewer with a new app. Just set your app release date to some time in the distant future and it will never actually show up in the app store if they approve it. If the new app comes back rejected for the same reason, you've got work to do, but if they do in fact approve it, then I would get on the phone with them and point out the discrepancy.
My approach would be to make sure that the compilation is absolutely clean both in the static analyzer (this is NOT optional, it will save you time!) and for the build itself. Then set everything as described on CocoaDev' NSZombie page. Then make sure you have an iPod running 3.2 (actual hardware, not simulator) and test, test, test. Do it with network available and not available, with the device nearly full and freshly restored, every other variation you can think of. Run it with the debugger active and as a release build disconnected. Use Leaks, Instruments and all the other tools to peek in there and get a better feel for what is happening. If you exhaust every possibility you are going to have to beg for more detail from Apple but I bet you find a problem - one of the most important things in debugging an issue like this is to try to forget everything you think you know for sure and start at the beginning.