dsym file

We're also seeing the same issue here. It was still working on July 20th for our last build, but the latest build uploaded on the August 4th 2021 did not have matching UUIDs. Is this being looked at? It's quite important for us to be able to upload the matching dsym files to Firebase Crashlytics.

I just created a new project in Xcode 16.2 and exported it for App Store distribution, and the Symbols directory is present, so that points to something with your project that's unusual. You're correct that the contents of the Symbols directory is used by the App Store to provide you with symbolicated crash reports from the field. Moving a step earlier in the process, those symbols need to be provided by the build as a dSYM file. So if you look in YourApp.xcarchive/dSYMs, what do you see? If that's empty, then work backwards from there to determine why your build is not producing dSYMs. — Ed Ford,  DTS Engineer

Thanks for the help! it is quite painful to have a single step take 7 seconds and more to get a variable's value... What do you mean by restore the dSYM in the Derived Data? In Build Options for my project, I changed debug information format set to DWARF with dSYM file (it was just DWARF before). It then ran a clean on the project, rebuilt it all... and I'm still getting 7 second single steps... Am I doing the right fix?

I doubled checked the Debug Information Format setting for my main target and it's set to DWARF with dSYM File. (Screenshot included.) I also did a new archive for both iOS and Mac (Catalyst), with no code or configuration changes between the two aside from the build number. When I inspect the contents of the archives, the dSYM for the main app is present in the iOS archive, but not the Mac archive. I'm using Xcode 13.3.1 and MacOS 12.3.1.

Did you try cleaning up your build directories (Command+Alt+Shift+K) after doing the change suggested above and then rebuilding your project? Otherwise you can set the Debug Information Format setting in your main project to DWARF for Debug and Release instead of DWARF with dSYM File and see if that resolves the problem.

A malformed dSYM file you think?That, or Xcode’s .dSYM Spotlight importer is not working. Either way, the absence of these attributes explains why symbolicatecrash is failing. On the Spotlight front, you can use mdimport to: get a list of the Spotlight importers — You’d expect to see Xcode’s importer (uuid.mdimporter) in that list.force a manual import of your .dSYM with that importer — This has debugging options so you can see what’s happening.Share and Enjoy — Quinn “The Eskimo!” Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

@ThomasATL Xcode 16: There is a warning: “empty dSYM file detected, dSYM was created with an executable with no debug info” That's a different message than the ones provided in multiple screenshots throughout this thread, The archive did not include a dSYM for SomeKit.framework with the UUIDS [...] If you have actionable steps to reproduce using only Xcode and Swift package manager in a test project, I can take a look, but it'd be better to fork that off to a new thread because this one is focused on a different error message, though they may seem similar on the surface. — Ed Ford,  DTS Engineer

When you go to Product > Show Build Folder in Finder, and then Build/Products/Debug-iphonesimulator/, is there a file in that folder named {YourApp}.app.dSYM? If not, go to Build Settings and search Debug Information Format and set this to DWARF with dSYM File for your Debug builds. (It's probably already set to this for your Release builds.) I hope this helps you. If anyone else can help further, I'm still facing the same issue: I've changed this build setting, and have the .dSYM in my Product subfolder, and I've added that folder to the Search paths for dSYMS under Instruments > Settings > Symbols, but I still don't see the symbols in my traces.

Hi all.My organization is also seeing this issue with all of our internal frameworks we create and distirbute. I went ahead and opened up a bug report (22855810) for this.For us we find the issue only occurs when we build the framework on one machine and then try to import it into another app on another developer's machine. The dSYM file warnings seem to mention diretories that have our user names or machine names hard coded into them.Sadly for us none of the project setting changes above reoslve the issue other than changing Debug Information Format to DWARF. Our concern though is that means we can't symbolicate crash reports since it seems we just bypass the dSYM file generation step?If anyone has any other information or ideas for a workaround or some other fix please let us knowThanks!

Has anyone found a solution to this? I'm having this same problem with the static libraries and frameworks that I create, and the only solution that seems to work is having the apps that integrates the library set their Debug Information Format to DWARF vs DWARF with dSYM File.DWARF seems to be the default setting for new projects created in Xcode 7, but existing projects that are migrating to Xcode 7 probably still have DWARF with dSYM File as the setting.It would be nice if someone from Apple could chime in on what the ideal solution is. 😐

@Edford I think the issue here is that the framework might have 3rd party dependencies (like mine), so the bcsymbolmap files that are produced are more than 2. This way we can't distinguish which are which and for sure there is no automated way to include the right ones in the xcframework. EDIT: I can confirm it worked for me too to include the dsym files by specifying the full path (from ~/...)

Yes, Include Symbols is set to Yes for me. So at least that part works. But the problem still persists that the UUID in the crash reports is different from the build on my machine (or in the dSYM file), presumably because it's the UUID for the bitcode build. So when I get crash reports, they're impossible to symbolicate because of the mis-matched UUIDs.

I'm also getting the same error, when linking to a framework that I've built with xcodebuild. This framework contains only arm64 libraries, one that targets the simulator and the other device. This warning goes away when I set DEBUG_INFORMATION_FORMAT to DWARF, but I don't consider that a full fix, since Firebase expects dSYM files.

Dietmar, I had a similar issue some time ago. It sounds like you've navigated a complex signing process, and you're very close! The error message clearly points to an issue with a debug symbol file (.dSYM) within your application bundle having an Apple-reserved bundle identifier (com.apple.xcode.dsym...). This typically happens when these files aren't properly handled during the deployment and signing process for third-party applications. Understanding the Error: The App Store Connect validation is rejecting your build because it found a .dSYM file with a bundle identifier that belongs to Apple. This suggests that either: Debug Symbols for Qt Plugins are Included Incorrectly: The .dSYM file for the libqtqmlcoreplugin.dylib (a Qt plugin) is being bundled in a way that retains Apple's internal identifier. Incorrect Handling of .dSYM Files during macdeployqt6: The macdeployqt6 tool might be copying these debug symbol files without the necessary modif

Thanks for the very interesting post. Experiencing discrepancies between crash reports from App Store Connect and other tools like Xcode Organizer or Firebase Crashlytics can be frustrating. If using Firebase Crashlytics alongside Apple’s built-in crash reporting, ensure there are no conflicts. Consider disabling one to see if crash reporting aligns with the other tool. Ensure that the correct dSYM files were uploaded for each build version. Mismatched or missing dSYMs can prevent proper symbolication. Check the build logs or archives in Xcode to confirm that dSYMs were generated successfully and uploaded. Use on the dSYM file to ensure it includes UUIDs matching those in the crash logs. Confirm that no third-party libraries are missing their dSYMs or are causing symbolication issues. During your testing, have you been able to reproduce the crash? Is the crash reported as terminated by the user? I would personally disable the third-party crash library to observe th