Systematic workflow for investigating TestFlight crashes and reviewing beta feedback using Xcode Organizer. Core principle: Understand the crash before writing any fix — 15 minutes of triage prevents hours of debugging.
Works with
AI-first code editor with Composer
Before installing skills in Cursor, ensure your development environment meets these requirements:
node --versionaxiom-testflight-triageExecute the skills CLI command in your project's root directory to begin installation:
Fetches axiom-testflight-triage from charleswiltgen/axiom and configures it for Cursor.
The CLI shows a list of agents. Use arrow keys and space to select Cursor:
Confirm successful installation by checking the skill directory location:
Restart Cursor to activate axiom-testflight-triage. Access via /axiom-testflight-triage in your agent's command palette.
We perform automated surface-level scans (Gen AI Scanner, Socket, Snyk) during installation. These checks detect common vulnerabilities but do not guarantee complete security. Always review skill source code and verify the publisher's reputation before production use.
Skills execute code in your environment. Always review source, verify the publisher, and test in isolation before production.
Submit your Claude Code skill and start earning
Automate repetitive workflows and reduce manual effort
Example
Generate reports, summarize documents, draft communications
Save 3-5 hours per week on routine tasks
Learn new skills, understand complex topics, get expert guidance
Example
Explain concepts, provide examples, suggest learning resources
Accelerate learning and skill development by 2x
Enhance output quality through reviews, suggestions, and refinements
Example
Review drafts, suggest improvements, catch errors
Improve work quality by 30-40% with less effort
0
total installs
0
this week
767
GitHub stars
0
upvotes
Run in your terminal
0
installs
0
this week
767
stars
Systematic workflow for investigating TestFlight crashes and reviewing beta feedback using Xcode Organizer. Core principle: Understand the crash before writing any fix — 15 minutes of triage prevents hours of debugging.
0x100abc123) → Go to Symbolication WorkflowNot all terminations produce crash reports. Check for:
pageOuts value0x8badf00d ("ate bad food")→ See Terminations Without Crash Reports
→ See Feedback Triage Workflow
Window → Organizer (or ⌘⇧O from Xcode)
┌─────────────────────────────────────────────────────────────────┐
│ [Toolbar: Time Period ▼] [Version ▼] [Product ▼] [Release ▼] │
├──────────┬──────────────────────────┬───────────────────────────┤
│ Sidebar │ Crashes List │ Inspector │
│ │ │ │
│ • Crashes│ ┌─────────────────────┐ │ Distribution Graph │
│ • Energy │ │ syncFavorites crash │ │ ┌─────────────────────┐ │
│ • Hang │ │ 21 devices • 7 today│ │ │ ▄ ▄▄▄ v2.0 │ │
│ • Disk │ └─────────────────────┘ │ │ ▄▄▄▄▄ v2.0.1 │ │
│ Feedback │ ┌─────────────────────┐ │ └─────────────────────┘ │
│ │ │ Another crash... │ │ │
│ │ └─────────────────────┘ │ Device Distribution │
│ │ │ OS Distribution │
│ ├──────────────────────────┤ │
│ │ Log View │ [Feedback Inspector] │
│ │ (simplified crash view) │ Shows tester feedback │
│ │ │ for selected crash │
└──────────┴──────────────────────────┴───────────────────────────┘
| Feature | What It Does |
|---|---|
| Speedy Delivery | TestFlight crashes delivered moments after occurrence (not daily) |
| Year of History | Filter crashes by time period, see monthly trends |
| Product Filter | Filter by App Clip, watch app, extensions, or main app |
| Version Filter | Drill down to specific builds |
| Release Filter | Separate TestFlight vs App Store crashes |
| Share Button | Share crash link with team members |
| Feedback Inspector | See tester comments for selected crash |
Crashes in the list show badges indicating origin:
| Badge | Meaning |
|---|---|
| App Clip | Crash from your App Clip |
| Watch | Crash from watchOS companion |
| Extension | Crash from share extension, widget, etc. |
| (none) | Main iOS app |
Before diving into code, ask yourself these questions (from WWDC):
→ Check the inspector's graph area on the right → Graph legend shows which versions are affected → Look for when the crash first appeared
→ Use the Release filter in toolbar → Select "Release" to see App Store crashes only → Select "TestFlight" for beta crashes only
→ Open the Feedback Inspector (right panel) → Check for tester comments describing their actions → Context clues: network state, battery level, disk space
When a crash has associated TestFlight feedback, you'll see a feedback icon in the crashes list. Click it to open the Feedback Inspector.
Each feedback entry shows:
| Field | Why It Matters |
|---|---|
| Version/Build | Confirms exact build tester was running |
| Device model | Device-specific crashes (older devices, specific screen sizes) |
| Battery level | Low battery can affect app behavior |
| Available disk | Low disk can cause write failures |
| Network type | Cellular vs WiFi, connectivity issues |
| Tester comment | Their description of what happened |
Example insight from WWDC: A tester commented "I was going through a tunnel and hit the favorite button. A few seconds later, it crashed." This revealed a network timeout issue — the crash occurred because a 10-second timeout was too short for poor network conditions.
Crash reports show raw memory addresses until matched with dSYM files (debug symbol files). Xcode handles this automatically when:
In Organizer, look at the stack trace:
| What You See | Status |
|---|---|
0x0000000100abc123 |
Unsymbolicated — needs dSYM |
MyApp.ViewController.viewDidLoad() + 45 |
Symbolicated — ready to analyze |
| System frames symbolicated, app frames not | Partially symbolicated — missing your dSYM |
If automatic symbolication failed:
# 1. Find the crash's build UUID (shown in crash report header)
# Look for "Binary Images" section, find your app's UUID
# 2. Find matching dSYM
mdfind "com_apple_xcode_dsym_uuids == YOUR-UUID-HERE"
# 3. If not found, check Archives
ls ~/Library/Developer/Xcode/Archives/
# 4. Symbolicate a specific address
xcrun atos -arch arm64 \
-o MyApp.app.dSYM/Contents/Resources/DWARF/MyApp \
-l 0x100000000 \
0x0000000100abc123
# 5. Symbolicate an entire crash log (parse + symbolicate in one step)
# Note: crashlog is an LLDB Python script, not a compiled tool.
# Works via xcrun but may not be available in all Xcode configurations.
xcrun crashlog MyCrash.ips
atos vs crashlog: Use atos for individual addresses (always available). Use crashlog to parse and symbolicate an entire crash report at once — it handles the full Binary Images section and resolves all addresses automatically.
| Symptom | Cause | Fix |
|---|---|---|
| System frames OK, app frames hex | Missing dSYM for your app | Find dSYM in Archives folder, or re-archive with symbols |
| Nothing symbolicated | UUID mismatch between crash and dSYM | Verify UUIDs match; rebuild exact same commit |
| "No such file" from atos | dSYM not in Spotlight index | Run mdimport /path/to/MyApp.dSYM |
| Can't find dSYM anywhere | Archived without symbols | Enable "Debug Information Format = DWARF with dSYM" in build settings |
# Verify dSYM exists after archive
ls ~/Library/Developer/Xcode/Archives/YYYY-MM-DD/MyApp*.xcarchive/dSYMs/
# Verify UUID matches
dwarfdump --uuid MyApp.app.dSYM
| Field | What It Tells You |
|---|---|
| Exception Type | Category of crash (EXC_BAD_ACCESS, EXC_CRASH, etc.) |
| Exception Codes | Specific error (KERN_INVALID_ADDRESS = null pointer) |
| Termination Reason | Why the system killed the process |
| Crashed Thread | Which thread died (Thread 0 = main thread) |
| Application Specific Information | Often contains the actual error message |
| Binary Images | Loaded frameworks (helps identify third-party culprits) |
The crashed thread's stack trace reads top to bottom:
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]
Start at frame 3 — the first frame in your code. Work down to understand the call chain.
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
Translation:
EXC_BAD_ACCESS with KERN_INVALID_ADDRESS = Tried to access invalid memory0x10 = Very low address, almost certainly nil dereferencecurrentUser.getter = Accessing a property that was nilProfileViewController.viewDidLoad() = During view setupLikely cause: Force-unwrapping an optional that was nil, or accessing a deallocated object.
What it means: Accessed memory that doesn't belong to you.
Common causes in Swift:
| Pattern | Example | Fix |
|---|---|---|
| Force-unwrap nil | user!.name |
Use guard let or if let |
| Deallocated object | Accessing self in escaped closure after dealloc |
Use [weak self] |
| Array out of bounds | array[index] where index >= count |
Check bounds first |
| Uninitialized pointer | C interop with bad pointer | Validate pointer before use |
// Before (crashes if user is nil)
let name = user!.name
// After (safe)
guard let user = user else {
logger.warning("User was nil in ProfileViewController")
return
}
let name = user.name
What it means: App deliberately terminated itself.
Common causes:
| Pattern | Clue in Crash Report |
|---|---|
fatalError() / preconditionFailure() |
Your assertion message in Application Specific Info |
| Uncaught Objective-C exception | NSException type and reason in report |
| Swift runtime error | "Fatal error: ..." message |
| Deadlock detected | dispatch_sync onto current queue |
Debug tip: Look at "Application Specific Information" section — it usually contains the actual error message.
What it means: Main thread was blocked too long and the system killed your app.
Time limits:
| Context | Limit |
|---|---|
| App launch | ~20 seconds |
| Background task | ~10 seconds |
| App going to background | ~5 seconds |
Common causes:
// 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)
}
}
What it means: System terminated your app to free memory. No crash report — just gone.
Symptoms:
pageOuts value in reportInvestigation:
Common fixes:
autoreleasepool for batch processingWhen users report "the app just closed" but you find no crash:
The Terminations Organizer (separate from Crashes) shows trends of app terminations that aren't programming crashes:
Window → Organizer → Terminations (in sidebar)
| Termination Category | What It Means |
|---|---|
| Launch timeout | App took too long to launch |
| Memory limit | Hit system memory ceiling |
| CPU limit (background) | Too much CPU while backgrounded |
| Background task timeout | Background task exceeded time limit |
Prerequisites
Time Estimate
15-45 minutes depending on use case complexity
Steps
Common Pitfalls
✓ Do
✗ Don't
💡 Pro Tips
✓ Use when
Use when skill capabilities match your task, clear ROI on time saved, and you can validate outputs. Best for repetitive tasks, learning, and quality improvement.
✗ Avoid when
Avoid when task requires deep expertise you can't validate, involves sensitive decisions, or when learning process is more valuable than speed of completion.
charleswiltgen/axiom
github/awesome-copilot
cexll/myclaude
github/awesome-copilot
github/awesome-copilot
microsoft/playwright-cli
Solid pick for teams standardizing on skills: axiom-testflight-triage is focused, and the summary matches what you get after install.
axiom-testflight-triage has been reliable in day-to-day use. Documentation quality is above average for community skills.
axiom-testflight-triage fits our agent workflows well — practical, well scoped, and easy to wire into existing repos.
Registry listing for axiom-testflight-triage matched our evaluation — installs cleanly and behaves as described in the markdown.
axiom-testflight-triage has been reliable in day-to-day use. Documentation quality is above average for community skills.
Solid pick for teams standardizing on skills: axiom-testflight-triage is focused, and the summary matches what you get after install.
Useful defaults in axiom-testflight-triage — fewer surprises than typical one-off scripts, and it plays nicely with `npx skills` flows.
I recommend axiom-testflight-triage for anyone iterating fast on agent tooling; clear intent and a small, reviewable surface area.
axiom-testflight-triage reduced setup friction for our internal harness; good balance of opinion and flexibility.
axiom-testflight-triage is among the better-maintained entries we tried; worth keeping pinned for repeat workflows.
showing 1-10 of 48