App Ops Desk · Issue #9

dSYMs and crash symbolication

A crash you cannot symbolicate is a crash you cannot prioritize. Solo founders lose days staring at hex addresses because dSYMs never made it out of the archive machine.

Read time: 6 min Crashes Post-upload Pairs with Issues #0 and #4
One action this week: For your last shipped build, confirm you can open a crash with human stack frames. If you cannot, fix dSYM retention before the next release candidate.

Why this bites solo shops hardest

Big teams have crash bots and dedicated release engineers. You have one Mac, one archive, and a TestFlight full of “it crashed.” Without dSYMs, every report is a riddle.

What must be true

  • You archived a Release build (not a random Debug install)
  • Xcode produced dSYMs for the app target
  • Dependency dSYMs are available when third-party code crashes
  • The UUID of the binary matches the dSYM you kept
  • Your crash tool (Organizer / third-party) can see those symbols

Failure modes

  • Cleaned DerivedData and lost the only dSYM copy
  • SPM/binary frameworks without symbols in the archive
  • Crash tool pointed at the wrong app / wrong bundle
  • Rebuilt “the same version” and overwrote UUID expectations

Boring retention rule

Every App Store / TF candidate gets a folder:

releases/1.6.0-241/
  ReleaseLog.md
  App.xcarchive/   (or exported dSYMs/)
  notes-for-testers.txt

If disk is tight, keep dSYMs + release log. Do not keep “I’ll re-archive from memory later” as the plan.

Copy/paste check

  1. Archive completes without dSYM warnings you ignored
  2. dSYMs stored outside DerivedData
  3. Build number recorded next to the archive path
  4. One sample crash (or Organizer crash) symbolicates cleanly

Bottom line

Keep dSYMs with the release log, not in disposable DerivedData. A crash without symbols is just expensive noise.

Resources hub → Reading order and jump-by-symptom links. Join the App Ops Desk waitlist Weekly release ops for people who ship alone.