dsym file

Thanks for the post, I would recommend to search the 3rd party libraries you include in the project to see what framework included those methods and replace them for better solutions. You can find references to those API in your app by using the command-line to check the app and the libraries it links against. You can do so by running the grep command in Terminal. First build and archive your app. Then Open /Applications/Utilities/Terminal Type the following on the command-line to change to the directory where the application binary is: cd ~/Library/Developer/Xcode/Archives// For example, cd ~/Library/Developer/Xcode/Archives/2020-03-09/SampleApp 3-9-20, 11.47 AM.xcarchive To search for _cJSON_Delete, _cJSON_GetArrayItem, _cJSON_GetArraySize, _cJSON_Parse, type the following on the command-line: grep -R _cJSON_Delete * grep -R _cJSON_GetArrayItem * grep -R _cJSON_GetArraySize * grep -R _cJSON_Parse * If there are references to cJSON_Delete, _cJSON_GetArrayItem, _cJSON_GetArraySize, _cJSON_Parse, you will get

I'm successfully adding the .dSYM to the XCFramework, but are the .bcsymbolmap files needed?

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

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.