Crash report reader for iOS and macOS
Drop the .ips file a tester mailed you, or paste a report from the Crashes organizer. The page tells you what kind of crash it is in plain words (EXC_BAD_ACCESS, a Swift trap, an uncaught exception, the 0x8badf00d watchdog and every other termination code Apple documents), shows the crashed thread with the frames from your code marked, and writes the atos and mdfind commands that turn your addresses into function names and line numbers. It all runs in your browser.
A JSON .ips from iOS 15+ or macOS 12+, an older text .crash, or a JetsamEvent report. Crash reports can include your customer's device details: nothing is uploaded, reading happens in this page.
Paste a crash report above, or drop the file, to read it.
Field names, exception types and termination codes follow Apple's Xcode documentation on crash reports, checked on 2026-10-31.
How it works
- •Since iOS 15 and macOS 12, crash reports are .ips files holding two JSON objects: one line of metadata (bug_type 309 for a crash), then the report. Addresses are stored as decimal numbers: each frame gives an image index and an offset, and the page adds the offset to that image's load address to get the address you see in a text report.
- •Your code is any binary inside your app's bundle: the main executable and the frameworks and extensions in it. Those frames are marked, and the first one on the crashed thread is where to start reading.
- •Exception types, subtypes, signals and termination codes are explained from Apple's Xcode articles on crash reports, with a link to the article for each one. Swift's own runtime message, Application Specific Information and the uncaught exception's name and reason are pulled out when the report has them.
- •For frames from your code that show only an address, the page groups the addresses by binary and writes the atos command with the right architecture, load address and dSYM path, plus an mdfind command that finds the dSYM by its build UUID.
- •Older text .crash reports are read too, including the bracketed list of addresses in an unsymbolicated Last Exception Backtrace. JSON reports also get a readable text version you can copy into an issue.
- •Jetsam event reports (JetsamEvent_…) are memory reports, not crashes: the page shows which process the system ended, why, and how much memory the largest processes used.
What it does not do
- •It doesn't symbolicate in the browser: that needs your dSYM, which should stay on your Mac. Copy the atos command and run it there. Crashes from TestFlight and the App Store arrive symbolicated in Xcode's Crashes organizer when the dSYM was uploaded with the build.
- •It doesn't decode thread registers or the VM region map beyond what the report already says, and it doesn't read hang reports, spin reports or stackshots (other bug_type values).
- •Explanations are about the kind of crash, not your code. A KERN_INVALID_ADDRESS can have many causes; the frame from your code and Apple's linked article are where the real answer is.
Questions
- Where do I find a crash report for my app?
- For TestFlight and App Store builds, open Xcode → Window → Organizer → Crashes. For a test device, connect it and open its logs from Xcode's Devices and Simulators window, or on the device go to Settings → Privacy & Security → Analytics & Improvements → Analytics Data and share the file that starts with your app's name. On a Mac, open Console → Crash Reports, or look in ~/Library/Logs/DiagnosticReports. Watchdog, code-signing, thermal and jetsam reports don't appear in the Organizer, only on the device.
- How do I symbolicate a crash report?
- You need the dSYM of the exact build that crashed. Its build UUID must match the UUID of your binary in the report's Binary Images. Find it with mdfind "com_apple_xcode_dsym_uuids == <UUID>" or in the .xcarchive's dSYMs folder, then run atos -arch arm64 -o <App>.app.dSYM/Contents/Resources/DWARF/<App> -l <load address> -i <addresses>. This page writes both commands from the report.
- What does 0x8badf00d mean?
- It's the watchdog's code, pronounced "ate bad food": the system ended the app because its main thread didn't respond in time, at launch or while running. The main thread's backtrace shows what it was doing; move that work (synchronous networking, large file parsing, database migrations) off the main thread.
- What is the difference between EXC_BAD_ACCESS and EXC_BREAKPOINT?
- EXC_BAD_ACCESS (SIGSEGV or SIGBUS) means the code touched memory it couldn't use: a NULL or dangling pointer, freed memory, read-only memory. EXC_BREAKPOINT (SIGTRAP) means code stopped the process on purpose, which in Swift is a runtime error: force unwrapping nil, a failed as!, an index out of range, overflow, fatalError or a failed precondition.
- Why does my crash say SIGABRT?
- The process called abort(). Usually that's an uncaught Objective-C exception (NSInvalidArgumentException for an unrecognized selector, NSRangeException for a bad index, and so on). The reason is in Application Specific Information, and the Last Exception Backtrace shows where it was thrown; the crashed thread itself only shows the abort.
- Is it safe to paste a customer's crash report here?
- The report never leaves your browser: the page makes no network requests with it. Crash reports can include device and file path details; if you share the readable version elsewhere, check it first.