• "A beta tester said my app crashed"
• "I see crashes in App Store Connect metrics but don't know how to investigate"
• "Crash logs in Organizer aren't symbolicated"
• "User sent a screenshot of a crash but I can't reproduce it"
• "App was killed but there's no crash — just disappeared"
• "TestFlight feedback has screenshots I need to review"

1. Open Xcode Organizer (Window → Organizer → Crashes tab)
2. Select your app from the left sidebar
3. Find the build version the user was running
4. Is the crash symbolicated?
   • YES (you see function names) → Go to Reading the Crash Report
   • NO (you see hex addresses like

     0x100abc123

     ) → Go to Symbolication Workflow
5. Can you identify the crash location?
   • YES → Go to Common Crash Patterns
   • NO → Go to Claude-Assisted Interpretation

1. Jetsam reports — System killed app due to memory pressure
   • Organizer shows these separately from crashes
   • Look for high

     pageOuts

     value
2. Watchdog termination — Main thread blocked too long
   • Exception code

     0x8badf00d

     ("ate bad food")
   • Happens during launch (>20s) or background tasks (>10s)
3. MetricKit diagnostics — On-device termination reasons
   • Requires MetricKit integration in your app

1. Xcode Organizer → Feedback tab (next to Crashes)
2. Or App Store Connect → My Apps → [App] → TestFlight → Feedback

1. Select a crash in the list
2. Click Open in Project button
3. Xcode opens with:
   • Debug Navigator showing backtrace
   • Editor highlighting the exact crash line

1. Select a crash
2. Click Share button in toolbar
3. Options:
   • Copy link to share with team
   • Add to your to-do list
4. When teammate clicks link, Organizer opens focused on that specific crash

• You archived the build in Xcode (not command-line only)
• "Upload symbols to Apple" was enabled during distribution
• The dSYM is indexed by Spotlight

• Frame 0 = Where the crash occurred (most specific)
• Lower frames = What called it (call chain)
• Look for your code = Frames with your app/framework name

Thread 0 Crashed:
0   libsystem_kernel.dylib    __pthread_kill + 8        ← System code
1   libsystem_pthread.dylib   pthread_kill + 288        ← System code
2   libsystem_c.dylib         abort + 128               ← System code
3   MyApp                     ViewController.loadData() ← YOUR CODE (start here)
4   MyApp                     ViewController.viewDidLoad()
5   UIKitCore                 -[UIViewController _loadView]

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000010

Thread 0 Crashed:
0   MyApp    0x100abc123 UserManager.currentUser.getter + 45
1   MyApp    0x100abc456 ProfileViewController.viewDidLoad() + 123
2   UIKitCore 0x1a2b3c4d5 -[UIViewController loadView] + 89

• EXC_BAD_ACCESS

  with

  KERN_INVALID_ADDRESS

  = Tried to access invalid memory
• Address

  0x10

  = Very low address, almost certainly nil dereference
• Crashed in

  currentUser.getter

  = Accessing a property that was nil
• Called from

  ProfileViewController.viewDidLoad()

  = During view setup

• Synchronous network request on main thread
• Synchronous file I/O on main thread
• Deadlock between queues
• Expensive computation blocking UI

// Before (blocks main thread — will trigger watchdog)
let data = try Data(contentsOf: largeFileURL)
processData(data)

// After (offload to background)
Task.detached {
    let data = try Data(contentsOf: largeFileURL)
    await MainActor.run {
        self.processData(data)
    }
}

• App "disappears" without any crash
• Jetsam report in Organizer (separate from crashes)
• High

  pageOuts

  value in report
• Often happens during photo/video processing or large data operations

1. Profile with Instruments → Allocations
2. Look for memory spikes during the reported operation
3. Check for image caching without size limits
4. Look for large data structures kept in memory

• Use

  autoreleasepool

  for batch processing
• Implement image cache with memory limits
• Stream large files instead of loading entirely
• Release references to large objects when backgrounded

1. Organizer → Select app → Look for "Disk Write Diagnostics" or "Hang Diagnostics"
2. These aren't crashes but system-initiated terminations

• Memory pressure (jetsam)
• CPU usage while backgrounded
• Background task timeout

1. "Was the app in the foreground when it closed?"
2. "Did you see any error message?"
3. "What were you doing right before it happened?"
4. "How long had the app been open?"

/axiom:analyze-crash

• "Analyze this crash log"
• "Parse this .ips file: ~/Library/Logs/DiagnosticReports/MyApp.ips"
• "Why did my app crash? Here's the report..."

1. Parse the crash report (JSON .ips or text .crash format)
2. Check symbolication status
3. Categorize by crash pattern (null pointer, Swift runtime, watchdog, jetsam, etc.)
4. Generate actionable analysis with specific next steps

• Interpreting exception types and codes
• Identifying likely cause from stack trace
• Explaining unfamiliar system frames
• Suggesting where to add logging
• Proposing fix patterns

• Whether the suggested fix is correct for your architecture
• How to reproduce the crash locally
• Priority relative to other bugs
• Whether it's a regression or long-standing issue

1. Sort by recency — Newest first, unless investigating specific issue
2. Scan screenshots — Visual issues are immediately apparent
3. Read comments — User's description and context
4. Check version — Is this fixed in a newer build?
5. Categorize:

• No direct reply — TestFlight doesn't support responding to feedback
• Screenshots only — No video recordings
• Limited context — Users often don't explain what they were trying to do

• Contact through TestFlight group email
• Add in-app feedback mechanism with more detail capture
• Include reproduction steps prompt in your TestFlight notes

1. Verify they're on TestFlight (not App Store, not dev build)
2. Confirm they've consented to share diagnostics (Settings → Privacy → Analytics)
3. Check for jetsam reports (kills without crash reports)
4. Check crash reports for their specific device/OS combination
5. Ask for specific reproduction steps
6. If still nothing: request screen recording of the issue

"I've checked our crash reports and don't see crashes matching your description yet. To help investigate: (1) Could you confirm you're running the TestFlight version? (2) What exactly happens — does the app close suddenly, freeze, or show an error? (3) What were you doing right before? This will help me find the issue."

1. Open Organizer → Crashes → Filter to the new build
2. Group crashes by exception type (look for the dominant signature)
3. Identify the #1 crash by frequency
4. Symbolicate and read the crash report fully
5. Understand the cause before writing any fix
6. If possible, reproduce locally
7. Fix the verified cause, not a guess

1. Paste full crash report into Claude with context
2. Ask for interpretation, not just "fix this"
3. Research exception type if unfamiliar
4. If still unclear after research, add logging around the crash site:

func suspectFunction() {
    logger.debug("Entering suspectFunction, state: \(debugDescription)")
    defer { logger.debug("Exiting suspectFunction") }

    // ... existing code ...
}

1. Ship instrumented build to TestFlight
2. Wait for reproduction with better context