ARTICLE AD BOX
What you're seeing is expected behavior.
plcrashutil convert does not symbolicate, it only converts the binary PLCrashReporter format into an Apple-style .crash text file. Symbolication is always a separate, post-processing step that requires matching dSYM files.
The reliable workflow is a two-step process, first you need to convert the uploaded crash report into a readable crash log:
plcrashutil convert --format=ios crash.plcrash > crash.raw.crash
At this stage the log is valid but unsymbolicated, next you'll need to apply symbolication by providing the correct dSYM files explicitly, which plcrashutil fully supports.
plcrashutil symbolicate \ --dsym /path/to/App.app.dSYM \ crash.raw.crash > crash.symbolicated.crashIf your app includes embedded frameworks, pass a directory containing all relevant dSYMs instead of a single file; this approach should work for device builds, ad-hoc builds, TestFlight, etc.. as long as the UUIDs in the crash log match those in the dSYMs. Simulaator crashes may already appear symbolicated due to host-side symbols but real devices always require correct dSYMs. There's no supported way to symbolicate at runtime or to "inject" symbols into a PLCrashReporter report; symbolication is intentionally a post-processing step based on UUID matching, mirroring Apple's own crash pipeline.
Best practice setup outside of their-party services is to archive dSYMs per app version, convert incoming .plcrash files server-side, symbolicate them using explicit dSYM paths, and retain both raw and symbolicated logs for analysis.
I hope this answers your questions.
