dsym file

The stable identifier for builds coming from Xcode is the build UUID that is embedded as part of the Mach-O metadata. This is what ties an executable or framework together with its associated dSYM file for things like crash symbolication. So rather than using a checksum (without knowing what you're trying to accomplish), you might be better off by looking for the build UUID. You can get it by running dwarfdump --uuid /Path/To/Binary. The build UUIDs produced by Xcode should be identical across builds for the following conditions: Exact same source code Exact same Xcode version Exact same build settings If any one of those conditions change, then the build UUID will change. But if you run back to back builds for the purposes of testing this, then the dwarfdump command will show you the builds are identical via the same UUID. We have documentation for this focused on what goes into debug symbol generation, but the Overview outlines what I said above. — Ed Ford,  DTS Engineer

Hi Eric, Symbols are being cached by the coresymbolicationd system-wide daemon that shares symbols resolving between all processes interested in them. You can operate on this cache (including removal of entries) by using symbolscache command that is available in /usr/bin. You can get more details on how to use it by just invoking it — you'll get a help description. Please note that because of removal from the cache, subsequent recordings will take more time, as Instruments will need to resolve the symbol again, instead of hitting the cache. Also: Remember that lookups will only be valid if the UUID is the same. In case you rebuild a binary, it'll get a different UUID and it'll again require a dsym file to resolve the the symbols. Out of curiosity: Why would you like to do it? I'm wondering if maybe there's something else that imposes a problem for you. Also, in case you care about symbols existing in the already saved trace files, you should be able to just remove corresponding .symbols file

Would creating an XPC helper [help]? No. App Review requires that all your executables be sandboxed, so your XPC service would hit the same limitations. Responses like xcrun cannot be used within an App Sandbox, I’ve talked about this before on DevForums, but it’s all a bit fragmented. I decided to collect everything together in a single post: Running Developer Tools from a Sandboxed App. Regarding the big picture, you wrote: I'm trying to perform the following operations: This is going to be a challenge. I’ll address each of the tools you mentioned, albeit out of order (-: dwarfdump to verify UUIDs This is the easiest of the lot. I expect it’ll work, subject to the limitations in Running Developer Tools from a Sandboxed App. atos to symbolicate with the found DYSM file This tool is a lot more complex than dwarfdump, so I’m a lot less happy to recommend it because of the ‘it might change in the future’ issue discussed in Running Developer Tools from a Sandboxed App. mdfind to locate DSYMs Th

It worked as described in above SO link. I had to add dSYMS and generated BCSymbolMaps files of linked framework.

The default value of DWARF_DSYM_FOLDER_PATH is $(CONFIGURATION_BUILD_DIR), so changing that will also change where the dSYMs get output to. Normally, during an archive build, CONFIGURATION_BUILD_DIR is set as some ArchiveIntermediates path, and I guess files from there get copied to the .xcarchive at some point. Changing SYMROOT can also affect DWARF_DSYM_FOLDER_PATH. If you must override either of those, you may need to manually copy the *.dSYM folders from your CONFIGURATION_BUILD_DIR to the .xcarchive/dSYMS/ folder, or set DWARF_DSYM_FOLDER_PATH to the desired output location.

I am getting some warning if i have uploading build in test flight Upload Symbols Failed The archive did not include a dSYM for the hermes.framework with the UUIDs [BB9F954C-2CB6-3528-9D45-D5E177F2D7CC]. Ensure that the archive's dSYM folder includes a DWARF file for hermes.framework with the expected UUIDs.