Xcode - UUID mismatch with framework dSYMs

I'm not sure why your build is resulting in inconsistent dSYM UUIDs. When we do these kinds of builds (having spot-checked a few now), we have consistent UUIDs.

However, in answer to your question about how you can symbolicate the crash reports you've already received given the .dSYMs you already have (assuming for the moment that although the UUIDs match, they refer to identical code, and thus would work).

I have found the following to work well if you have to force the specific dsym:

atos -arch x86_64 -o <path_to_dsym_within_package> -l <offset_of_framework>

It's certainly not as pretty and generally I run the individual addresses through atos manually, but the result is a valid routine/line combination (assuming that you match the correct versions, etc.)

The <path_to_dsym_within_package> refers to foo.framework.dSYM/Contents/Resources/DWARF/foo followed by your binary name, where foo is the name of the framework. For us this works for any kind of plugin as well.

The <offset_of_framework> is from offset column in the crash log, where:

0 libsystem_kernel.dylib 0x7fff8e785ce2 0x7fff8e76f000 + 934101 libsystem_c.dylib 0x7fff871afa7a 0x7fff8716e000 + 2689222 CTUtils 0x104e26c62 0x104e17000 + 64610

In this case, the first hex number is the address, the second hex number is the starting offset for the particular framework, and the + value is the decimal offset within the framework.

You'll need the second number (hex offset) for the command line above, and the first number to find the specific routine/line number.

In a worst-case scenario, there's always using dwarfdump directly, by using:

dwarfdump <path_to_dSYM> --arch x86_64 --lookup <offset>

<path_to_dSYM> is the path to the top level ".dSYM" folder (unlike the atos command above), and <offset> is the offset within the module, which isn't as convenient as atos.

P.S. atos should be installed in /usr/bin/atos if you have the dev tools installed.

I encountered this problem too. After some investigation, it turned out that Xcode was copying debug framework builds into release builds, but, apparently, creating dSYMs from the correct release binaries.

This was despite using Xcode to add the framework dependencies from the workspace. Eventually I found out why: the frameworks were included the project with their location "Relative to Group" for some reason. After I made sure all were "Relative to Build Product", it solved the problem for me. Not saying it is the only possible cause, but it's worth double-checking all the paths in the build log, because Xcode won't warn about anything in this case.