Is it possible to use TestFlight Live for analytics and crash reports for my App Store submitted app?
If so, how does it work? Can I get symbolicated crashes? The documentation for TestFlight Live is not very extensive. I know it's beta, but I'd like to know more about it.
Yes, you can use Testflight Live for "some" analitics, like how many current users, nr of unique users used your app, how many sessions, avg time for a session etc.
It's best to try it yourself to test. It's easy to setup, include the SDK in your project, and then one line of code to takeoff.
You can do more things, like adding code so you can show questions to your testers after finishing level 1 asking if it was too easy or not (as an example).
Symbolication is possible, you can upload your .dSYM file.
Check out Crashlytics for your crash reports. It's very lightweight and easy to setup. It also gives very detailed (which line the program crashed) results.
Related
My boss has an individual Apple developer program. Normally when there are error in his apps, he would just tell me the errors, but lately the errors are too many, so now he just sent me the crash report from Flurry.
The thing is, it is not symbolicated. And when I tried to symbolicate it in my computer, the app is not the same archive with the one sent to Apple, so I didn't get anything. And this also poses a problem when there are many archives.
This symbolicate process is confusing to me. Is there an easy way to find the errors and symbolicate it using my XCode for the apps published using my boss' XCode?
Using flurry or any other way (Apple's own Crash report?)
Thanks a bunch.
There is no way you can pass a core dump to get your hands on it to debug, but there are several tools can help gather the crash report for you.
I am using Crashlytics to collect the crash report, and it will send you email to let you know a new crash happened or a regression, beatiful UI design and already decoded the symbols for you. It's very easy to setup and absorb. Just check it out.
Crashlytics is bundled with Fabric, including many new features you may need in the future.
Apple recently announced its own crash reporting tool, you could also consider. But I am still stick to Crashlytics since there is no reason not to...
If you know the trick, you can decode the symbols on your own, just search how to do it.
I can recommend crashlytics of fabric.io.
Is there any ways to know what's wrong with someone's app. It is working on everyone else's device but this person.
The person tried removing the previous version and installing the new one, but it still does not work. I suspect that one of the files that I place in the documents folder might still be there... but the format of this file has changed since...
Apple has a technote about this named Debugging Deployed iOS Apps.
Also, if your tester syncs up their iPhone with a Macintosh or PC, iTunes also helpfully moves logs into predictable places where they can be retrieved from.
I am attempting to solve this logging of execution in TestFlight with the following simple approach...
In in-App Billing you really have to use TestFlight, so the problem is serious.
The "print("text") statements can be replaced in the code to calls to a func printTestFlight(text: String) which writes the strings to a database along with some identifier so you know the user.
This is quite simple and obvious, and to an extent it works.
If there are events which are logged by the os rather than teh user, then this approach misses those, notably the interesting ones around a crash. I'd be happy to hear from anyone who knows how to do thiso
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?
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.
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.)
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
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.
Can anyone suggest me what is the best way/procedure/library to include in IOS app before submitting to app store to generate detail Crash Report , without compromising app efficiency.
is iTune connect procedure is reliable ?? Can any one suggest me any good library ?
Here's a good overview of various libraries, I know Crittercism by reputation but it would be worth evaluating for yourself: http://www.jeremyfuller.net/2011/06/the-battle-of-the-ios-crash-reporters/
iTunes Connect has become more and more reliable as time goes on. Their current crash reports are doing the trick for us.
Flurry also has a way of catching exceptions that crash our applications, so that's useful too.
Not sure if that is possible. But what happens is, sometimes our app randomly crashes. We don't know what exactly the problem is. Is there a way for us to get the crash report off user's iphone? By code, or by another app?
Thanks.
You can inject a third party code in your app, which would basically save your crash reports and thereafter you can use them for analysis. The way we do is capture any crash logs and upload them to the app server, which uses the info to display through a user-friendly web Interface (access controlled for admin purposes).
A great open source Crash Reporter library can be found here https://github.com/kstenerud/KSCrash
It's the user who decides from Settings > General > About > Diagnostics & Usage whether to automatically send crash reports or not.
You can also use a third party component to get detailed information about crash events, for example Crittercism.
If you're interested in 3rd party services for crash reporting for iOS it's hard to go past Crashlytics. Very fast crash reporting, simple installation, great response times to queries.
I'd also mention the TestFlight SDK, which is free and easy to use, and allows you to gather crash reports easily from all your testers, and also do remote logging and other stuff. I used it on a location based app I was working on a while ago, and it was very helpful with debugging