In the controller UI, iOS crashes are not symbolicated by default. To get human-readable crash stack traces that can be easily understood, use a platform-specific mapping file that can translate the raw data into human readable output.
iOS users can review the below diagnosis and solution.
For Android, see "Upload the ProGuard Mapping File" in Instrument an Android Application - Manual.
iOS crash snapshots can be symbolicated using the debug symbols (dSYM) file. The crash snapshots are processed only once by the EUM Server, so if the dSYM file is not present at the time of processing, the snapshots will not be symbolicated.
Crash report example:
0xd8000 - 0x12ffff+ECommerce-iOS armv7 <feaae512eb613a75a33dee253fa87bb6> /var/mobile/Containers/Bundle/Application/C64FEBB0-EF8E-4079-BDE0-E35C531F0CA2/ECommerce-iOS.app/ECommerce-iOS
In the above example, the string
feaae512eb613a75a33dee253fa87bb6 is the universally unique identifier (UUID) of the application. To symbolicate the crash reports, upload the dSYM file with the corresponding UUID.
The dSYM file was generated when the application was built. If you rebuild the application later, it almost always will have a new and different UUID. It is possible to set up your environment to upload the file automatically each time you build.
For crash reports to be symbolicated, the corresponding dSYM files need to be uploaded to AppDynamics.
Users can either set up their environment to upload the file automatically each time they build or choose to upload the file manually.
Crashes that have already been processed will not be symbolicated retroactively, but all future reported crashes will be symbolicated.
Note: Crash snapshots are processed only once by the EUM Processor, therefore if the dSYM file is missing during the time of processing the snapshot, it won’t be symbolicated. Even if the user uploads the dSYM file later, the EUM Processor will not retroactively process these snapshots.