iOS crash reports are technically available and practically useless until you symbolicate them. Apple gives you a .crash file full of memory addresses, and the only thing that turns those addresses into your function names and line numbers is the matching .dSYM. Miss that match and you're staring at a stack trace that tells you a crash happened somewhere, which you already knew.
BugSplat's iOS integration captures the crash and does the symbolication for you, against the build that actually crashed, and groups it with every other report of the same fault. You get a readable call stack, the device and OS version, and whatever custom context you attached, in one dashboard instead of buried in Organizer or a user's email.
dSYM matching is the entire job
Everything about reliable iOS crash reporting comes down to getting the right .dSYM to BugSplat. Build with debug symbols in a separate dSYM bundle, and upload that dSYM matched to your release. Get it right and every report is readable. Get it wrong and you've got addresses.
There's one timing wrinkle worth knowing if you're using the Unreal plugin or a similar build setup: the dSYM often isn't generated until after the main build step finishes, so an automatic upload during the initial build can miss it and catch it on the next incremental build instead. It's not a bug, it's just build-phase ordering, and our docs show how to add a custom build phase if you want the upload to happen reliably every time. Worth setting up once so you never wonder why a particular build's crashes came back unsymbolicated.
Setup, briefly
You add the BugSplat iOS SDK, point it at your database, and configure your symbol uploads. Our BugSplatTester sample for iOS gives you a working integration to look at, and the docs cover the dSYM upload paths including the automated route. The integration itself is quick; the part that earns its keep is wiring symbol upload into your pipeline so it's never a manual step you can forget under launch pressure.
One field note that's saved people real confusion: iOS apps sometimes won't crash while the USB cable is connected during debugging. If your test crash isn't firing, disconnect and re-run. It's the debugger interfering, not your integration.
What you're actually buying
The ability to know, the morning after a release, exactly which line is crashing your iOS users and how many of them are hitting it. Not "we're seeing some crashes." The specific symbolicated stack, on the specific build, with a count. That's the difference between reacting to App Store reviews and fixing the thing before the reviews show up.
Crash data should be usable, not just available. On iOS, usable means symbolicated, and symbolicated means getting your dSYMs to us. Do that one thing well and the rest takes care of itself.
Full iOS setup is in the docs: docs.bugsplat.com
Want to see your own iOS crashes symbolicated? Start a free trial and send your first report.