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.
Related
I have an application that uses HealthKit and Swift in it, everything compiles and runs fine when I test it from Xcode on a simulator or a device. I tested, debugged it, and submitted it to the iTunes store. When the application was approved I downloaded the new version from the store and it crashed right away. This was extremely puzzling as I have never had this issue before. I look at the diagnostic and usage logs on my phone and the crash report for the application says this:
Dyld Error Message:
Library not loaded: #rpath/libswiftCore.dylib
Reference from: /path/to/my/app
Reason: no suitable image found.
Did find: /path/to/my/app/Frameworks/libswiftCore.dylib: mmap() error 1 at address=0x100174000, size=0x0194000 segment=__TEXT in Segment::map()
Has anyone seen anything like this or know how to deal with it?
Thank you
EDIT:
The crashing issue magically fixed itself on the morning of October 4th, which tells me that this was an Apple issue. I have been emailing iTunes Connect Support, but they have not said one way or another what happened. I also opened a technical ticket without even a response back from Apple. This is pretty disappointing, not just for the fact that Apple is not being transparent about the issue, but also it makes me feel like I have no course of action later on down the road if this ever were to happen again.
Simply do the following two steps:
1) Delete the App from the device (or simulator)
2) Clean your workspace (CMD+SHIFT+K or via menu Product->Clean)
3) Build and run your app again.
Magically helps every time with all that startup / deploy stuff...
I also often get something like "application not found on device" or signing problems etc. Minutes before everything worked well.
This appears to possibly be a code signing issue on Apple's part, and the issue seems affect apps with embedded frameworks (including non-Swift apps). There are multiple accounts of developers being affected (myself included) who had only submitted an update, without changing any build settings. Some high profile apps appear to have been affected and tickets have been filed with Apple, but there has been no official response from them at this time.
EDIT: This has been confirmed.
Edit:
The app was rejected, after making this change, for the same reason, however, I am confident that the problem has to do with a missing architecture version in the libswiftCore.
I am going to post this as the provisional answer.
Xcode 6 Standard architectures exclude armv7s
Notice how the error says: Did find: /path/to/my/app/Frameworks/libswiftCore.dylib
So it did find the lib but it also says: Reason: no suitable image found.
After running lipo against the archived build it didn't contain armv7s in the swift library, or in the app binary. I manually added it per the link above and the binary now contains support for armv7s though the swift library still did not. My app is in expedited review so I should get feedback farily quick. I will follow up when that does happen.
I had the exact same problem with one of my app version updates (FunKeyBoard 1.1).
After doing some research, looks like it was an Apple side issue for many apps updated on October 3rd. Apple fixed the issue on October 4th by releasing an update, same version number, without needing any fix/re-upload from the app developer.
Obviously an Apple side issue, but I'm surprised Apple is very quiet about it. Many developers, including myself, got angry emails from users, and poor app reviews, as a result.
This error typically occurs when signing Swift apps with certificates that lack "OU" (Organizational Unit). All certificates created after the release of iOS 8 should have this. The simple solution is to create a new certificate to sign with.
For more details, see the official Apple comment here: https://developer.apple.com/library/ios/qa/qa1886/_index.html
It seems that my on the iTunes store is now downloading and opening as expected. From what I have been reading in the Apple Developer Forums, other apps are also working now too. I have not received any word from Apple on why this happened or what caused this. I opened up a technical support ticket with them and I also contacted iTunes Connect support and there is no
explanation or any information on this issue being resolved. This is pretty poor customer service on their part.
I had the same problem. I removed support for arm64 and added armv7s and now apple review team approve the app.
After making an update to an iPad app I released some time ago, I've been getting reports that people are unable to actually update the app without deleting and re-installing. However, as far as I know, nothing in the update should be causing this. (All the update deals with is letting people email PDF documents, nothing major.) When people attempt to update, they're asked for their iTunes password, but after entering it, it merely goes back to the update screen and nothing happens. Additionally, it would seem that this only happens with my app, the people in question aren't having any issues with the other various apps on the App Store. Does anyone know what might be causing this and how I could fix it?
Thanks in advance!
(Also, if it matters, the app is a custom B2B app, the general public can't purchase it.)
I'm removing the text of my answer because it's so inaccurate it's embarrassing. I mistook "B2B" for "Enterprise" and answered based off of that. To make up for it, I'll look into the problem a bit more and if I find anything I will edit this answer accordingly.
Edit:
Okay, I can see why you put a bounty for this question on SO; there's not really any data on a problem like this anywhere. Frankly, there's not much available information on B2B in general. I'll post what I found anyway, in case it can be of any help to you.
I found the details reason behind Maggie's question, there. Per Editing and Updating App Information:
Updates keep the same Apple ID and bundle ID, which means they are
associated with your first version and free to your customers
Also, apparently, "You can't change the CFBundleIdentifier of a released app if you want to release updates for it, the App Store will automatically reject it when you upload." which is something I can vouch for, having experienced this with a normal app. I do know that for a B2B app you do have to submit it to Apple for review, but I can't tell from the documentation I found if you need to actually submit it to the App Store, so it may not go through the various checks that normal apps go through, so this could be your problem.
Aside from that, according to the VPP guide, if your customers are installing the apps on the devices with Apple Configurator (broken right now, per app store reviews) the updates also have to be done with the Configurator. You haven't said that Configurator was involved, but I did find this tidbit.
• Use Apple Configurator to install apps on new or supervised devices.
Apple Configurator on a Mac makes it easy to mass configure and deploy
devices that are centrally controlled. Redemption code spreadsheets
acquired through the Volume Purchase Program can be imported by Apple
Configurator, tracking the number of apps installed on each device. To
update deployed apps using Apple Configurator, you must reconnect to
the same Mac from which the apps were installed. Learn more at
itunes.apple.com/us/app/apple-configurator
Anyway, good luck. Wish I could be more help.
What you are describing (assuming that it is accurate) would certainly be a bug on Apple's side. If users are trying to update the app and the update is not being processed, then in one way or another that is a bug that Apple needs to address. Nothing that you do as a developer should be able to cause that situation to happen. I would suggest contacting Apple and possibly filing a bug report.
It seems that apple wants you to develop the Iphone apps in the latest build. Sometimes this cause issues between realeases (diferent versions of Itunes, OSX, IOS, etc) when you try to update your apps.
Try to publish the app in the latest version of xcode.
That happens a lot in iphone development testing.
Hope this help.
When updating an app, iOS looks for the bundleId and if there is another app with the same bundleId, it updates the app with the highest version number. Maybe the version number is not set correctly or maybe people have issues because an other app (from the AppStore or an other B2B app) have the same bundleID but a higher version number.
I'm by far not an iPhone expert, but it seems something related might have been fixed in iOS 6.0.1.
Fixes a bug that prevents iPhone 5 from installing software updates
wirelessly over the air
I have noticed that when performing native debugging on Xcode 4 if I have my app installed, then delete the app, then attempt to debug again from Xcode 4, the time it takes to perform the step "Transferring package" is pathologically slow. Has anyone else experienced this? I dread deleting the app as it will take 20-30 minutes to load the app.
Our app has lots of user files that get deleted when app is deleted. Perhaps some sort of sync-like process is running at same time. Killing Xcode 4 does not fix the issue.
I think now you must use Xcode 6.3 and it will allow you to do everything in easiest way. Here this version of Xcode is most stable version I have worked with for last few years.
I would like to offer some general guidance on this as the symptom you see can have many causes. In fact most versions of Xcode have had these symptoms for differing reasons in my experience.
I've seen the slow transfer problem before (Xcode 4 I think), when I switched my app to be an app that could run in the background. To get around that, I would either force kill the app from the phone itself, or I would change the bundle id of the app when deploying it (as a hack).
68cherries commented on seeing the problem after profiling. Doing profiling of a device generates a lot of data on your Mac, and perhaps also on the device but I don't know. So its worth switching phones with another phone, ideally one that has a lot of free space; does the problem follow the phone?
Sometimes deploying has a problem when resources are missing; resources are rebuilt upon clean. Try pressing the option button and then doing a clean - it cleans intermediate files. (option-shift-command-k). This can happen in particular when you delete a resource but still reference it from a story board. Going through the story board looking for exclamation mark warnings is helpful (particularly with Apple Watch apps).
Periodically it is worth doing a resource file audit. Quite often we deploy files not actually needed by the target device. For example, bash script files, old icons, etc. The fewer resources, the fewer things that can be incorrect, and can often trigger an idea about what has changed with your resources that might explain the problem. It also makes the deployment smaller for your customers.
Note with this problem its worth debugging it from both sides. For example, look at your Mac console logs to see any errors, or your activity monitor for unexpected behaviours and tasks. On the device side, its worth installing iOS console from lemonjar.com to see if anything got to the device end and if there were errors there.
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.