For iOS applications, the raw data in the stack traces in crash snapshots consists of memory addresses of stack frames that point to executable application code. It also includes symbols and memory offsets for the system library code used by the application. Such a partially symbolicated stack trace looks something like this:

Splunk AppDynamics attempts to display stack traces with the names of functions with offsets into those functions to help you identify the line of code that was executing when the application crashed. To get the symbols that map to the executable code, it needs the dSYM (desymbolication) file for the crashed application.

If the dSYM file for the crashed application has been uploaded, the symbolicated stack trace shows the function name and the offset into the function where the app crashed. It looks something like this:

The dSYM file is created when the application source code is compiled with the DWARF with dSYM file Debugging Information Format set to

If a dSYM has been uploaded for a crashed application, in the crash list the Symbolicated column for the associated crash snapshot is true.

If the symbolicated property is false and you want to see user-friendly stack traces in your crash snapshots for this application, you need to locate and upload the dSYM file for the crashed application.