Using dSYM files to symbolicate crash reports

WHAT THIS TESTS The interviewer wants to see that you understand why release crash logs are opaque and how the debug-symbol artifact restores meaning, plus the operational discipline of keeping dSYMs.

A GOOD ANSWER COVERS Release builds are compiled with optimizations and have symbol information stripped from the shipped binary to reduce size and protect details, so a crash report lists raw memory addresses per stack frame rather than function names. A dSYM, a debug symbols bundle Xcode produces beside the optimized binary, stores the mapping from those addresses back to function names, source file paths, and line numbers. To make a report readable you symbolicate it: the crash log and the dSYM each carry a UUID, and only the dSYM whose UUID matches the crashing binary can resolve its addresses. Xcode's Organizer can symbolicate automatically when it has the archive, or you can use symbolication tooling with the dSYM to translate each address into a file and line.

COMMON WRONG ANSWERS Confusing the dSYM with the app binary itself. Thinking any dSYM works regardless of UUID. Not archiving and storing the dSYM for every released build, so when a crash arrives months later there is nothing to symbolicate against, especially with Bitcode recompilation where Apple generated new dSYMs to download.

LIKELY FOLLOW-UPS Why must the UUID match? How do crash reporters like the Apple service or third parties handle dSYM upload? What changes when Bitcode recompiles the binary on Apple's servers?

ONE CONCRETE EXAMPLE App Store Review rejects build 42 for a crash whose log shows only hex addresses under your app's binary. You retrieve the archive for build 42 from the Xcode Organizer, which contains the matching dSYM whose UUID equals the crash log's binary UUID. Xcode symbolicates the report, turning a frame like 0x0001a2f4 into ProfileViewController.loadAvatar at ProfileViewController.swift line 88, immediately revealing a force-unwrap of a nil image URL that you then fix.