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.
Related
I am going to launch my app on the AppStore and I would like to keep track of crashes and fix them as soon as possible. If possible, it would be nice to collect also some additional information about user activity and other useful stuff.
In order to do so, I have looked for some crash reporting tools and the most interesting ones I have found are: TestFlight Live, QuincyKit and Crashlytics.
Among those three, QuincyKit should be the lightest one but the other two seem to be quite interesting since they provide more sophisticated reports and other interesting stuff.
My goal is to have as many information as I can on any issue the user can experience, but at the same time I don't want to make the app slower or consume more resources.
In your opinion and from your personal experience, which of these tools is the best one (taking into account my goal and my needs)?
By using TestFlight Live or Crashlytics I would make my app too slow?
Is there a risk to overload the device?
Reports provided by QuincyKit are precise enough? How many information can I retrieve from them?
Thanks!
Here is what I decided:
I am using Crashlytics for crash reporting (yes, it seems to be really great) and TestFlight for tracking user activity (checkpoints are really useful to find out what users generally do and figure out what the tendency is).
I followed the instructions written here
I honestly think Crashlytics is a better solution than Testflight for crash reporting.
Here's what you get with Crashlytics that you don't get with the others.
Duplicate culling (TF does this too, but its not too great at it, Crashlytics is damned near perfect)
You can actually mark crashes as closed/resolved, and get them out of your list for a given version.
Crashlytics does everything TF's Crash reporting does, but better and then some (logging, stack traces, etc.)
Percentage of affected users, and the numbers that go with that. (ie: should i fix the bug that happened to one guy, or the one that's happening to 10k?) Testflight doesn't tell you this.
Prioritization based on occurrence. This is probably the most important gain in my opinion.
These are just a few, but I figure they're probably the most important ones for you.
We used Testflight's crash reporting for close to 2 years on an extremely popular app (several million D/Ls). Its definitely better than nothing, and very convenient if you're using TF for distribution as well, however you get many more benefits from Crashlytics. We switched to Crashlytics this summer and now we're actually able to manage crashes and make smart decisions about what to fix and when, instead of just sifting through a giant never ending list.
I see you already accepted an answer, but I'd seriously give it another look even if you opt to continue with Testflight. I've found its hard to really grasp what you're missing until your app has shipped, at which point is even harder to change.
Crashlytics is second to none for crash reporting.
We were in the same boat as you trying to find the best crash reporting solution. After some thorough investigation and test runs of TestFlight, HockeyApp, and Crashlytics, we originally chose HockeyApp because they allowed us beta distribution along with crash reporting on both iOS and Android (we wanted both in one solution for both platforms). However, HockeyApp's exception backtracing was just not giving us any additional crash details. This is where Crashlytics shines. Their exception backtracing is amazing. Period.
So here's my summary of all 3 SDKs:
Crashlytics
#1 crash reporting
#1 exception backtracing, bar none (provides very useful extra crash details)
Extremely fast and lightweight
Custom key logging for additional crash context
Best duplicate crash recognition and culling
Automatic SDK updates (Their Mac app automatically updates the Crashlytics iOS SDK in your project)
No beta distribution (I'd love a one stop solution for crash reporting and beta distribution)
Automatic build server support
TestFlight
Somewhat heavy, and adds bloat to your app package
Great beta distribution
No Android support (at least when we tested back 6+ months ago)
HockeyApp (HockeyKit - Beta distribution, QuincyKit - Crash reporting)
Lightweight
Crash reporting UI a bit confusing
Exception backtracing severely limited (at least when we tested in March of 2011)
Very good beta distribution
All that said, we chose Crashlytics for crash reporting, and HockeyApp for beta distribution. But you must chose what works best for your needs.
Definitely recommend Crashlytics as well.
TestFlight Live has given me issues in the past. It seems every time I go to use TestFlight, it is down anyway.
Crashlytics is awesome. Here's why:
Adding it to your project couldn't be easier. There is a Mac app that does most of the hard work for you.
Automatically updates itself
Prioritizes crashes for you
Provides handy stats like OS and device percentages as well as average memory available, etc
I use Crashlytics in all of my applications. I added it to Hipstamatic when I was there and the data we got was shocking. It really helped improve our product. I also tried TestFlight Live and quickly removed it after the first beta since it was causing crashes.
Crashlytics is awesome. You should use it.
If we're only talking about crash reporting, Crashlytics is far better than TestFlight. (Never tried QuincyKit, so I can't compare the 3 options)
We've been using Crashlytics for over a year on Weddar and it has been great. Having tried other solutions before I have to say that before installing it I was kind of suspicious of the great features they were stating, but the installation was indeed done in about 5 minutes and it only added around 40-45Kb to the app.
The crash reports are incredibly detailed making it really fast to pinpoint solutions for the bugs and the updates to the sdk are pretty steady and stable. The team is incredibly supportive too. I remember that we had a problem with the new ARM7s when iPhone5 came out and they solved it in about 30 minutes.
I use TestFlight for user beta testing management so I've tried TestFlight Live SDK in the summer just to see if it was a solution to have all integrated in one service, but we had a really bad experience with it. I had 2 updates rejected in the App Store Approval for the first time (Weddar was launched in April 2011) and we lost about a month trying to catch the bug. When LIVE beta testing, no user would complain about any problem, we "solved" it by removing the TF SDK. Never quite understood what was the problem. We contacted TestFlight team and never had contact back. (Another big big detail is that TF SDK added about 800Kb to our app.)
So, even if I still use TestFLight for beta testing, if you're looking for a great and lightweight crash reporting SDK, I definitely say that you should use Crashlytics.
Hope this helps.
I'd say go with TestFlight (Live)
In my experience the TestFlight SDK won't crash/slow-down your device and has very versatile crash reporting - allowing you to debug reported errors fairly accurately.
TestFlight also doubles-up as a feedback package for when you're testing in-development.
It's also a pretty light SDK.
To be more specific (in answering your list of questions):
TestFlight allows you to scalp for user 'checkpoints' and has its own version of NSLog that allows you to dynamically log events at runtime.
Your app wouldn't slow down as network requests are handled off the main thread.
I don't understand why a device would get overloaded by using either of the SDKs you've mentioned.
QuincyKit reports seem reasonably precise, however you need to make up your own mind about the precision you need - you can find QuincyKit docs here.
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 was wondering if anyone has any experience with uploading applications.
At the moment we have an application without any leaks, and how hard we even try to create a crash, in both the simulator and the actual device it just wont let us crash it.
Now we're curious if there are any other developers out there that has been in the same situation and sent their applications to the app store and what the actual outcome was. As we're very cautious and dont want to waste our company's resources we'd like to get as much feedback as possible and cover everything before submitting to the app store.
Please feel free to share.
Thanks in advance!
Ensure you don't use any undocumented API's immediate fail.
Follow the Apple criteria and make sure your app fits their restrictions....
Check my post App Store Approval which contains a link to the criteria....
Good work having a thoroughly tested app and I admire your desire to ensure your submission is pain-free. Good luck!
If it does want you want, and you are happy with the amount of testing you've put in it..and it follows Apple's app store guidelines, I'd say its ready for the app store. Quite a large number of apps have huge glaring bugs, so if yours never crashes (doubt this), you are one of the very few.
Also, the process only takes about a week, so I wouldn't say its the end of the world if it somehow gets rejected or you find a bug later.
You can create an ad hoc build and send the application to some iPhone users and ask them for feedback on application. And if app crashes just get the application logs from itunes.
Apart from running a private beta or adding a crash reporter, there isn't much more to do than checking the App Store Review Guidelines and send your first version.
One issue I ran into is that the plural of a word counts as a whole different keyword. Example, looking up snippet won't return applications tagged snippets so be sure to include both of them.
I have an app that I occasionally receive support emails for that say the app crashed on them and won't open up anymore. It shows 'Default.png' then exits. Even when the app is deleted and reinstalled.
-I get no crash reports or memory issues (as reported by itunes connect using reports from a significant sample size >20k downloads)
-I've confirmed it's not limited to a specific model and not caused by jailbroken devices.
-The app doesn't have external dependencies, so why would reinstalling it not fix the problem?
What kind of problems could cause the crashing to go unreported and be persistent?
If you have an uncaught exception handler, depending on what you have in there, you will not get reports written out the same way, or at all, as if you did not have a handler. This will make iTunes think there is not any crash reports at all. Uncaught exception handlers are commonly added as part of analytics frameworks, or third party notification tools.
While this could answer your question, a more reasonable explanation is that the crashing devices just need a device restart.
I think every app developer with a sizable install base has struggled with an issue like this in the past.
Are you using any sort of analytics package, such as Flurry, that helps you report crashes? We used Flurry with much greater success over Apple - Apple won't start reporting crashes to you until you have many -- and "just a few" is never enough.
Additionally, if it shows the default.png and crashes, take a hard look at your start-up code. Are you setting something in NSUserDefaults, that if, corrupted, could cause the app to crash on startup?
Admittedly it is strange that a delete-and-reinstall doesn't do the trick.
The users aren't reporting the error reports to Apple. The crashes could come from any number of sources.
You could walk a user through the process of digging crash reports directly out of iTunes during the next Sync and email them directly to you.
You could try asking a user to delete the app from the device, reboot their device, then have them install the app again after a fresh reboot.
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...