I have problem with Crashlytics (and with crashes shown in Xcode -> Organizer) because I don't see many of crashes that I should. From testers I should have many crashes there but I don't have. I logged into iTunes Connect and get zipped dSYM files there and upload them to Crashlytics to see new crashes. But even if it said that there is one or more new crash after upload dSYM I dont see any new crash. It looks like most of crashes I dont see in Crashlytics. Why is that? I need to get logs/crashes from devices that runs app from TestFlight. I think with Objective-C and before bitcode it worked much better.
Edit:
Is it possible that in another tool (from 3rd party company) there would be crashes that aren't in Apple Organizer? I am asking if I should try more tools from other companies. Maybe some of crashes are because of memory. Is it possible that these crashes aren't in reports?
Thanks
Fabric shows 1 crash 'row' for each crash, the number of crashes is in the same row.
But remember, crashes are only send to crashlytics if the user opens the app again.
You could also test Crashlytics by using:
Crashlytics.sharedInstance().crash()
First make sure you have uploaded your dsym files to your crashlytics dashboard, Check this
Click on the encircled part
Then on your Xcode > Window > Organizer
Tap Download dSYMs, When the download is complete right click your Archive and click Show in Finder, then right click the package and tap Show Package Contents
Open the dSYMs folder, then you can just drag and drop those dSYMs to the Crashlytics Dashboard
I think that your problem is related to two things:
As Gerrit said in the other answer crashes are sent to Crashlytics if the user opens the app again;
The crashes in Xcode --> Organizer are displayed only if the user sets on the share of analytics with App Developers.
For more informations take a look at this link: Share analytics, diagnostics, and usage information with Apple.
If people doesn't share the analytics you won't see any crash.
EDIT: I found that your problem may also be related to the debugger...for more information check this thread and see if you can find your solution here --> Crashlytics is not sending Crash report from iPhone.
I hope to have been helpful!
If the application is crashing before the like in your AppDelegate where you are setting up Fabric/Crashlytics then the crashes are not going to get sent through properly.
It may also be that the crashes you are experiencing are being filed as Out-of-memory crashes by Crashlytics.
Related
I just implemented Fabric Crashlytics tool to my Xcode project via Swift Package Dependencies.
All works good if I enable Google Analytic on a step when I create an app, without this step I did not received crash reports, so I switched to the app with Google Analytic enabled.
I've tested crash button from the link:
One comment that I don't like from there
"After your app crashes, run it again from Xcode so that your app can
send the crash report to Firebase."
Does it mean that user has to reopen app to send crash report? For example if a user download an app from the App Store and then somehow the app is crashed. Does mean that reopening app required for sending that crash? And if the user will not open the app it means I lost this crash report? I understand that on live store there is no option to re run it form Xcode, but reopening seems a require step.
I suppose the crash report should work different a bit by sending issue details right after a crash, I may be wrong here.
Also when I set everything via Swift Package Dependencies looks like I don't have an option to upload dSYM via this option
/path/to/pods/directory/FirebaseCrashlytics/upload-symbols -gsp /path/to/GoogleService-Info.plist -p ios /path/to/dSYMs
Does this mean I need to pull Fabric and Crashlytics from CocoaPods?
I've switched off bitcode at the moment and looks like all is works automatically but not sure it is good idea for long perspective.
Yes, crashes will be uploaded when restarting the app after it crashes. As far as I know, this is because the SDK may not have enough time to actually send the report when the crash happens.
If you are using Swift Package Manager, you still have that option.
This is the command:
"${BUILD_DIR%/Build/*}/SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/run"
If the app has bitcode enabled, then you'll need to download the dSYMs from the App Store and upload them manually.
Lastly, Fabric is now deprecated so don't download it. You don't need to use Cocoapods if you are already integrated Crashlytics with SPM.
I have implemented a Firebase crashlytics in my project, and also I have configured the firebase account with my project. But when I do a crash with the help of Crashlytics.sharedInstance().crash() I will get crash crash report perfectly. But if I do a crash with any other method, it is not showing up the crash report. But some crashes are showing in the dSYMs tab in crashlytics and it is not formatted correctly. I have downloaded the dSYM file from the iTunes store and uploaded to Crashlytics through terminal. But Still I am getting the crashes in the dSYMs tab and not formatted correctly.
This is How I am getting crash report in dSYMs tab in Crashlytics.
Does anybody know what I am doing wrong here?
I could able to implement it in my Swift project and it correctly decrypted the errors and displayed correctly. But when I implemented it into my Objective-C project, I am not getting the correct decrypted report.
When having "optional" missing dSYMs, those are usually related to .frameworks or other third party library being used. If you only have these kinds of missing dSYMs, the dashboardwill show the crash report, but the frames related to those dSYMs won't be symbolized.
DSYMs marked as "required" are related to your main app, when those are missing, the dashboard won't show the crash report.
Usually, when using a .framework, the dSYMs files should also be available, but if not, you'd probably need to get them from the framework owners.
To elaborate Gerardo's answer further, please refer to your Xcode Organizer. There goes a list of your app published with different version. Download the dSYM
reports first and hence follows the procedures given from Google and submit those dSYM to firebase
Make sure you have already installed the latest version of FirebaseCrashlytics via Cocoapods and proper app profile at your Firebase Console.
https://firebase.google.com/docs/crashlytics/get-deobfuscated-reports#upload-dsyms
I have searched a lot for a solution to my case but no answer. I proceed with the installation for crashlytics on iOS, but the crashes don't appear on crashlytics. There are no missing DSYM, and I set the 'Debug Information Format' to 'DWARF with dSYM File'. I tried a lot of solutions but no one fit my case. Any help is appreciated!
when I press run I get the following from fabric window
the updated output of the console when I press run
Looking at the output from your log, it seems like you're using Firebase Crash Reporting and not Firebase Crashlytics. If you want to use Crashlytics, you need to remove the Firebase Crash Reporting SDK (you can't have 2 exception handlers in iOS apps) and then follow the instructions for installing and setting up Firebase Crashlytics.
I have an app in beta using TestFlight and I have been noticing crash reports appearing.
most of the reports are this
If I click on the button Open in project in the Organizer it takes me no where
This appears to be an internal crash correct?
How can I find out what UIBarButtonItem is causing the crash?
I Hope this will help you: Apple doc Crash Report , as you can see in the doc in the Listing 4 the crash report is fully symbolicated , Listing 6 shows partially symbolicated crash reports which looks like your case
From Apple Doc
You must keep both the application binary and the .dSYM file in order to be able to fully symbolicate crash reports. You should archive these files for every build that you submit to iTunes Connect. The .dSYM and application binary are specifically tied together on a per-build-basis, and subsequent builds, even from the same source files, will not interoperate with files from other builds. If you use Xcode's Build and Archive command then they will be placed in a suitable location automatically. Otherwise any location searchable by Spotlight (such as your home directory) is fine.
For more information about this you can check portion after Listing 6 in Symbolication
you can use crashlytics for identifying where the app is crashed.It will give the Controller name and line number of code also.
https://docs.fabric.io/ios/index.html Document
Easy to add your project also
Currently, my crash organizer looks as follows.
I have not really worked with crash logs before, but to me the crashes do not look symbolicated. I am unable to find where the app has crashed and for what reason. In addition, when I open the stack trace in the project, nothing is highlighted and I cannot tell and which line it crashed in the file. My question is: is there a way to symbolicate all these crashes from within the organizer, or must it be done through terminal?
Thanks.
What you're seeing is that the SDK classes like UITableView are symbolicated, but classes from your "YLSA" app are not. Both should be symbolicated automatically, but in my experience one or the other (or both) often do not symbolicate. I've been developing for iOS for five years and this has been a persistent problem through all the different Xcode versions.
I'm seeing the same problem as you in Xcode 7, but I was able to symbolicate my logs with this workaround:
In the list of crash logs, right-click the desired log and select Show in Finder. This will show you a package containing one or more .crash files and some metadata.
Navigate through the package until you find a crash log. You will see that the same info has or hasn't been symbolicated here.
In Xcode, open the Devices window and select a connected device, then click the View Device Logs button.
Drag the crash log in step 2 from the Finder into the list of logs for this device.
When I do this, I never see the log I added appear in the list, but if I click the headings once or twice to re-sort the list, then I see it.
After a moment, the crash log will become completely symbolicated.
If you already have a lot of logs in your list, you can compare the date, iOS version and hardware model as you view the log in the Finder to the logs in Xcode to make sure you're viewing the same log. Then look at the line that says "Triggered by Thread" to get the thread number that crashed, then scroll down to that thread to see the code that triggered the crash.
This worked for me today with Xcode 7. I hope it helps you!
When you submit apps through Xcode, an option will appear to include debug symbols. Next time you submit an app version, be sure to select that; if you did not, that might explain the problem you're seeing. Unfortunately there's no way to retroactively do that for app versions already submitted, so you'll have to wait until you're ready to submit the next version to see if that was the problem.