Crashes show raw memory addresses instead of function names? Learn why Sentry cannot symbolicate your iOS crashes, including the App Store recompiled-dSYM trap, and how to fix each cause.
The symptom is unmistakable once you have seen it: a crash appears in Sentry, but instead of a readable stack trace with function names, source files, and line numbers, you see rows of hexadecimal memory addresses, module names, and offsets. The issue is captured, so this is not a delivery problem, but the trace is nearly useless for debugging because you cannot tell what code was running. This happens when Sentry does not have the dSYM debug symbol file that matches the exact binary that crashed. Sentry symbolicates on its servers by mapping the crash's memory addresses back to symbols using the dSYM, and it matches the correct dSYM to the crash through a unique debug identifier baked into both the binary and its symbols. If the matching dSYM was never uploaded, or the uploaded one does not match, symbolication fails and you are left with raw addresses. Every fix for this problem comes down to getting the right dSYM, identified by the right debug ID, into Sentry for the build that produced the crash.
The most basic cause is that no dSYMs were uploaded for this build at all. Sentry does not obtain your debug symbols automatically; you must send them with sentry-cli, an Xcode build phase, or the Fastlane plugin. If you set up the SDK but skipped the symbol upload step, every crash will be unsymbolicated. Check your project's Debug Files section in Sentry settings, sometimes labeled Debug Information Files, which lists every dSYM Sentry has received. If it is empty or missing entries for your current release, that is your answer. The fix is to upload the dSYMs for the crashing build. For an already-shipped build, locate its .xcarchive in Xcode Organizer, show package contents to find the dSYMs folder, and run sentry-cli debug-files upload against it with your org and project. Going forward, automate the upload so it happens on every release build. This single missing step is responsible for a large share of unsymbolicated-crash reports, especially in projects where the SDK was added quickly without completing the symbol setup.
This is the subtle, frequently-hit case. If your app went through bitcode processing, or you enabled Xcode's option to include app symbols on upload, Apple recompiles your binary on their servers during processing. That recompiled binary has different debug identifiers than the one your local Archive produced, which means the dSYMs you uploaded from your machine no longer match the binary your App Store users are actually running. Crashes from those users cannot be symbolicated by your local dSYMs. The telltale sign is that TestFlight or ad-hoc crashes symbolicate correctly while App Store crashes do not. The fix is to obtain the Apple-generated dSYMs and upload those. In App Store Connect, open your app, select the processed build, and download the dSYMs, or use the Download Debug Symbols action on the archive in Xcode Organizer. Then upload the downloaded files to Sentry with sentry-cli exactly as you would your own. Because these symbols only exist after Apple finishes processing, this must be a post-submission step, which many teams script to run once a build is available.
Sometimes dSYMs were uploaded, but they still do not match the crash because their debug IDs differ from what the crashing binary needs. This can happen if you uploaded symbols from a different build, if a rebuild changed the binary without a fresh upload, or if your build process produces non-deterministic binaries so that the archived build and the one you extracted symbols from are not identical. Every Sentry crash event lists the exact debug ID it requires in the event details, under the image or debug metadata. Take that ID and search your project's Debug Files in Sentry for it. If it is not present, you uploaded the wrong symbols. You can confirm the debug IDs of your local dSYMs using sentry-cli's debug-files check command or the difutil tooling, then compare against what the crash needs. The fix is to find the dSYM whose debug ID matches the crashing build and upload that specific file. Keeping archives of every shipped build makes this recoverable; discarding them means the matching symbols may be gone for good, so preserve your archives.
You cannot upload symbols that do not exist, and a misconfigured build setting can prevent Xcode from generating them. Open your target's Build Settings and check Debug Information Format. For Release and Archive builds it must be set to DWARF with dSYM File; if it is set to plain DWARF, no dSYM file is produced and there is nothing to upload. Debug configurations frequently use plain DWARF for speed, which is fine, but your shipping configurations must generate dSYMs. If you inherited a project where this was changed, or a build script stripped symbols, you will have no dSYMs for those builds and their crashes can never be symbolicated retroactively. The fix is to correct the setting and rebuild, then ensure the new builds upload their symbols. This cause is worth checking early because no amount of upload configuration helps if the files were never created in the first place. Confirm the setting, then verify a fresh Archive actually contains a dSYMs folder with files inside before moving on.
Occasionally the upload appears to succeed but the symbols land in the wrong place or are rejected. If your sentry-cli command targets a different org or project than the one receiving the crashes, the dSYMs are stored where the events are not, and symbolication fails. Double-check the --org and --project values in your upload command or build phase against the project your DSN points to. Similarly, if your auth token lacks the necessary scopes, uploads can fail silently in a build phase whose errors you never read. Ensure the token has project write and release permissions, and check the build log for the sentry-cli output rather than assuming the phase succeeded. A build phase that fails quietly is a common way for symbol upload to break without anyone noticing until a crash comes in unsymbolicated. Add logging or fail the build on upload error during development so you catch these problems immediately. Verifying the target project and token scopes takes a minute and rules out a whole class of silent upload failures.
After uploading the correct symbols, confirm the fix rather than assuming it worked. First, check the Debug Files section in your Sentry project settings and verify the debug ID the crash needs is now present. Note that Sentry symbolicates new events as they arrive; a crash that was already ingested unsymbolicated may not automatically reprocess, though Sentry can reprocess events in some plans and you can trigger it where available. The cleanest verification is to reproduce a crash on the same build after the symbols are uploaded and confirm the new event shows a readable trace. Going forward, make symbol verification part of your release checklist: after each build ships, confirm its dSYMs, including Apple's recompiled ones for App Store builds, are present in Sentry before you rely on that release's crash data. It also pays to keep a short record of which debug IDs correspond to which shipped versions, because when a months-old release suddenly starts crashing you can locate and re-upload the exact matching symbols without guesswork. Preserving every build's .xcarchive means you can always recover and re-upload symbols later if needed. With upload automated and verification habitual, unsymbolicated crashes become rare, and the ones that do slip through are quickly traceable to a specific missing debug ID you can go and supply.
Because Sentry does not have the matching dSYM debug symbol file for the crashing build. It symbolicates server-side using dSYMs you upload, matched by a debug ID. Without the right dSYM, addresses cannot be translated into function names and line numbers.
Apple recompiles your binary during processing when bitcode or symbol inclusion is involved, producing new dSYMs with different debug IDs than your local ones. Download the Apple-generated dSYMs from App Store Connect or Xcode Organizer and upload those to Sentry so they match the shipped binary.
Every Sentry crash event lists the required debug ID in its event details, under the image or debug metadata. Search your project's Debug Files for that ID. If it is missing, the matching dSYM was never uploaded. Use sentry-cli to check your local dSYMs' debug IDs and find the match.
New events are symbolicated as they arrive. Crashes already ingested without symbols do not always reprocess automatically, though Sentry offers event reprocessing on some plans. The most reliable verification is to reproduce a crash on the same build after uploading and confirm the new event is readable.
Then those crashes can never be symbolicated retroactively. Check Build Settings and ensure Debug Information Format is DWARF with dSYM File for Release and Archive configurations. Fix the setting, rebuild, and confirm the archive contains a populated dSYMs folder before shipping.