Symbolicating iOS crash reports
Debugging an iOS application crash sometimes involves analyzing crash reports. More info about crash reports can be found in the Apple documentation.
Crash reports generally require symbolication to become properly readable: symbolication turns machine code addresses into human-readable source locations. The document below describes some specific details of symbolicating crash reports from iOS applications using Kotlin.
Producing .dSYM for release Kotlin binaries
To symbolicate addresses in Kotlin code (e.g. for stack trace elements corresponding to Kotlin code)
.dSYM bundle for Kotlin code is required.
By default, Kotlin/Native compiler produces
.dSYM for release (i.e. optimized) binaries on Darwin platforms. This can be disabled with
-Xadd-light-debug=disable compiler flag. At the same time, this option is disabled by default for other platforms. To enable it, use the
-Xadd-light-debug=enable compiler option.
In projects created from IntelliJ IDEA or AppCode templates these
.dSYM bundles are then discovered by Xcode automatically.
Make frameworks static when using rebuild from bitcode
Rebuilding Kotlin-produced framework from bitcode invalidates the original
.dSYM. If it is performed locally, make sure the updated
.dSYM is used when symbolicating crash reports.
If rebuilding is performed on App Store side, then
.dSYM of rebuilt dynamic framework seems discarded and not downloadable from App Store Connect. In this case, it may be required to make the framework static.
Decode inlined stack frames
Xcode doesn't seem to properly decode stack trace elements of inlined function calls (these aren't only Kotlin
inline functions but also functions that are inlined when optimizing machine code). So some stack trace elements may be missing. If this is the case, consider using
lldb to process crash report that is already symbolicated by Xcode, for example:
This command should output crash report that is additionally processed and includes inlined stack trace elements.
More details can be found in LLDB documentation.