We have an app live with thousands of daily users. We released a new version in phases, where the current 2% phase is paused.
We use fabric/crashlytics for logging the crashes. The Environment class is reading data from the Keychain, and is developed by ourselves. The error of the crash is errSecInteractionNotAllowed.
Fabric reports 121 crashes in our Environment class on version 2.1.2, while XCode only reports 3 crashes on the same version.
The only reason we can think of: We read something about iOS calling the app in the background while automatically updating the app. When the device is locked during the update, the Keychain will be locked as well. This would result in a crash. It might happen that Apple doesn't report this crash, since it is caused by the Apple updating system.
Is there any other clue that explains the difference between Fabric and XCode crashes?
To see the Xcode crashes, users have to explicitly enable a setting "Share crash reports with apple and developers" (I think thats what its called) either during phone setup or later on via iOS settings app. If they don't enable it, you won't see anything. Most people I know don't enable it as they are worried about privacy.
Crashlytics doesn't require users to agree to sending reports. So its extremely likely crashlytics will report a higher volume of crashes.
Related
With the new feature of iOS 13 to report crashes for TestFlight builds, on some apps I have a problem that only feedback.json is reported without actual crash report.
Is there anything to enable?
Worth to mention that crashalitics is enabled and not reporting any of the crash.
Update: so after some investigation, I found that reports without a crash logs are system terminations. In my case when I extracted device logs from the phone and it was 0xbadf000d, one of the meanings is system terminated a long process in the background. Seems it was always there, but with iOS13 Testflight feedback it becomes visible with popups.
By the wat, somehow logs from Xcode "Devices and simulators" are not in sync with logs directly on the phone.
Takeaway: Faced a need to manually simbolicate a crash report, so found super useful stackoferlow post: https://stackoverflow.com/a/45207863/3032917
This happens when the watchdog kills the application due to some reason. we can check the logs in the Analytic & Improvement section
I am facing the same issue, the system terminates the network extension due to some reason. And, many users has downloaded the app from test-flight and they are seeing the default crash alert from OS. since test-flight feedback does't contain crash logs, i am not able to identify the problem.
Encountered the same behaviour when the specific device was on low storage. The device has less than 50 MB remaining from 30GB of storage.
You mixed up the crash log and crash feedback of TestFlight.
What you see in JSON format is Crash Feedback. It is available since iOS 13 devices and can be obtained by App Store Connect > TestFlight.
For Crash Log, it can be found in Xcode > Organizer > Crashes. If you cannot see the logs, it will appear few hours later (but please make sure dSYM is enabled when you're uploading the archive to the App Store Connect).
I have a serious issue which I cannot seem to solve.
Recently I have made an update to an IOS app, and when testing in XCODE as both Ad-Hoc, Debug, and installing via the .IPA on a device the issue cannot be replicated. However when I download the app from the App Store, it crashes.
Does anyone know how this could happen, and any potential solutions? I am getting lots of complaints from users, and not sure what to do?
Could part of the binary upload have got corrupted?
Probably you always compiled your app in debug mode. But when sent to App Store you made a release compile. click the arrow in the run button select scheme and chose "release mode" and run your app it will probably crash.
check if you used NSParameterAssert as they are not called in release mode
I cannot say why your live App Store application is crashing and the debug version is not. Two possible solutions:
Crash reports:
To find out why your application crashed, you might want to check if there are any crash reports available on iTunes Connect. Log in on iTunes Connect and click on your application. Scroll down to Crash Reports. You will find out more about why your application is crashing here.
More information about crash reports here at Apple's own iOS Developer Library.
Prerelease your app with TestFlight: For in the future: test your application by uploading it on iTunes Connect and testing it with TestFlight first before submitting the application to the iTunes Store. This will save you a lot of (review) time if you find a error.
I realize this is an old thread but I had the same issue with my App that I released. Meaning it worked fine in testing, but when I released it it would crash. The culprit ended up being the fact that I am using In App Purchases. I have two items that can be "bought" but I had only enabled one of them. In testing it was able to read both of them, but with the release version, it was only pulling the one that was enabled down, creating the crash. The fix was simply enabling the disabled item. I didn't even have to redistribute the app, though I had to wait for it to "percolate" through... Anyway this may help someone in the future.
Check if your app is looking for too many IAPs.
I just had this problem and my problem was I had deleted an IAP from the App Store, but didn't remove it from the app code.
For some reason it only crashed when downloaded; I used a promo code to do this before launching my app.
Thanks to Tornado for the inspiration to try this variation.
I was using Evernote and it crash once, So after crashing I reopen it and it ask me for submit crash report to developer.
After some googling I have found in my iTunes Connect Account in Application detail there is one option called Crash reports.
So my conscience is that how to enable crash report submission in Application.
If the app asks for sending crash reports this has nothing to do with iTunes Connect.
The reports you see in iTunes Connect are send automatically by the phone (or iTunes?) when the user has agreed to send diagnostic reports when they set up their device. This happens automatically, you don't have to configure anything at all. Just go to iTunes Connect and get the crash reports.
But to be honest, iTunes Connect crash reports seem a little bit unreliable. If you see them at all it takes almost forever until you see them. Another culprit is that you have to check for new reports manually.
So Evernote, like basically everyone else, switched to a 3rd party service for crash reporting.
I use crashlytics in my own apps. But there are many others.
A good read might be Ray Wenderlichs Overview of iOS Crash Reporting Tools: Part 1/2 and Part 2/2
Some personal experience:
Since my apps don't crash often I usually see "Too few reports have been submitted for a report to be shown." in iTunes Connects crash reporter. But when I open the console of crashlytics is see 6 different crashes right now. Most of them affect only two or three people but it's good to be aware of new issues, even if few people are affected.
iTunes Connect does not show crash reports for prerelease versions of iOS. But it happened that I had a horrible bug in my app that lead to a crash instantly after people opened the settings of my app on a prerelease version of iOS. After the first crash report came in via crashlytics I fixed that bug and submitted an update. Because I didn't have time to test against the first betas it would have taken a while to be aware of this crash if I had relied solely on iTunes Connect.
We have an app live in the app store for almost an year, and we've been receiving several bad reviews from customer which cannot open the app after updating it.
Users have reported they are unable to launch the application following deleting and subsequently reinstalling the application.
One user did indicate they could launch the application only following a factory reset of their iPhone.
We believed the issue was related to the Keychain, since this seems to be persistent in the system. For this reason we updated the third party library we are using to access the keychain to https://github.com/soffes/sskeychain. This change was made in version 1.4.1.
After releasing 1.4.1, a couple of users indicated they were finally able to open the app. Unfortunately, as we are unable to debug the issue we were unable to determine what possible issue might have been resolved. Furthermore, we saw other users still having the same issue upgrading to 1.4.1 and also to 1.4.2.
We are also considering the issue may be with one of our dependent libraries:
Flurry analytics
Facebook iOS SDK
PayPal MPL
Hockeyapp ios lib
ASIHTTPRequest
we do not use CoreData
We are unable to debug this with the standard iOS tools and we can't even expect hockey app to provide us a crash report since the app is closed before sending it.
This behaviour we do not understand, and we clearly have no control on the app while is being updated from the app store. Is there anything that persists for an application on its deletion? If not, are you aware of anything that might prevent the opening of the reinstalled app?
EDIT:
we are configuring hockeyapp lib in applicationDidFinishLaunching: app delegate's method in this way:
[[BITHockeyManager sharedHockeyManager] configureWithIdentifier:QUINCY_APP_IDENTIFIER delegate:self];
[[BITHockeyManager sharedHockeyManager] setDisableUpdateManager:YES];
[[[BITHockeyManager sharedHockeyManager] crashManager] setCrashManagerStatus:BITCrashManagerStatusAutoSend];
[[BITHockeyManager sharedHockeyManager] startManager];
#ifdef DEBUG
[[BITHockeyManager sharedHockeyManager] setDebugLogEnabled:YES];
#endif
the app identifier is configured in the build settings and distinct per each configuration.
In general there can be multiple issues happening on startup:
A required library is not linked correctly: But this can NOT be the issue, since then all app starts would crash!
Startup is taking taking too long and the app is killed by the watchdog.
This could be your problem if you are doing e.g. migration of a lot of data on the main thread right in the applicationDidFinishLaunching: runloop and hence the app is not responsive for user input and hence will be killed by the watchdog after about 20 seconds.
Make sure to do migration without blocking the main thread!
You are experiencing a crash (not a kill!) on startup. Since the app crashes before the HockeyApp SDK can send the crash, you won't be able to get those crash reports.
The HockeyApp iOS SDK provides a mechanism to handle these, follow the instructions given in the following page: http://support.hockeyapp.net/kb/how-tos-faq/how-to-handle-crashes-during-startup-on-ios
So either 2. or 3. are your issue. If you have a chance to directly contact a user who is affected, you could ask for the iOS generated crash report. Otherwise check the recommendations I gave.
We had this problem once. The app worked fine as an Ad Hoc build. Apple tested and approved it; however, end users would crash immediately upon opening.
For us, it turned out to be that we were not properly passing our HockeyApp production API key in correctly.
Once we got that fixed users were good to go. For Example:
[[BITHockeyManager sharedHockeyManager] configureWithBetaIdentifier:#"betaKeyHere"
liveIdentifier:#"liveKeyHere"
delegate:self];
I can't believe it, but I finally found the reason why the app crashes.
[[NSLocale currentLocale] objectForKey: NSLocaleCountryCode] sometimes returns nil.
I made the assumption this was always valid, but apparently I was wrong.
I found this other question here NSLocaleCountryCode returns nil. it should be the right place for a follow up on this issue.
Thanks to #kerni suggestion I was able to made hockeyapp send reports of application launching crashes, but unfortunately this wasn't enough to understand what happened: the stack trace of the report was not clear.
After a couple of tries, I discovered another bad bad thing related to flurry. This was capturing the system exceptions and avoid hockeyapp to correctly handle the crash and produce a reasonable report.
This discussion was very helpful for me to identify and correct my flurry integration code: http://support.hockeyapp.net/discussions/questions/1359-more-information-for-crashes-with-reason-no-reason-found
After this change, I was finally able to see a decent crash report on hockeyapp and identify my issue: the current locale.
We developed an app, and it works perfectly on several different emulators and devices, not once crashed, but both times we tried submitting to Apple it gets back to us as "2.1 - apps that crash are rejected" (or something).
I cant seem to find the log from them, or any additional infos. Is the crash log available anywhere? Or just ANY info? They only say that it crashed on an iPad 3rd Gen with iOS 6. We ran on a device like that and it didnt crash for us.
Unfortunately, Apple doesn't provide detailed logs of their review process, although crash logs are sometimes provided, as indicated by #jsd in the comments below.
In theory, crash reports get synchronized with iTunes and can be collected by Apple and provided to you via iTunes Connect, but in practice, that rarely works - or only with large delays.
However, you could integrate some Crash Reporting into your App. Here are a few services that allow you to do that without much hassle:
HockeyApp
Crittercism
BugSense
TestFlight
Crash reporting integration in production versions of my apps have been proven to be very helpful, so I'd highly recommend this. Good crash reporting services provide an SDK to be included in your app, and generate symbolicated, readable, ready-to-use crash reports that make tracking bugs very easy.
As for the cause of your app's crash, here are some basic guesses:
Do you use ARC (Automatic Reference Counting)? You should.
Did you run the Static Analyzer in Xcode (Product ➞ Analyze)?
Did you test with different environments (e.g. internet connection via 3G, WiFi or none at all)?
Have you deleted and reinstalled the app on your device, or did you just update it?