dsym file

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.

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

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.

@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!

@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 ~/...)

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. 😐

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.

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

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.

The first thing I tried was using the built-in Xcode crash reports in the Organizer. I assumed that since Xcode has access to the archives and is fetching the crash reports itself, it would be able to locate and use the appropriate dSYMs, but I see unsymbolicated entries for the parts of the stack trace that are in my app. So that led me to trying to symbolicate manually. I looked up the UUID and then used this, which produced no output: mdfind com_apple_xcode_dsyms_uuids == E49A5EB3-C560-3895-B2AE-4CEE263E45CA Next I tried looking in the archive for the dSYM itself. I right-clicked on the archive in the Xcode organizer and chose Show in Finder, then used Show Package Contents on the xcarchive. In the dSYMs folder, I see dSYM files for some frameworks the app uses, as well as some of its extensions (intents, widgets) but there isn't a dSYM for the app itself.

Documentation bug reported, as FB14929037. Yes - the offset from the string is quite large, but I just want useful output such as ThisFunctionWasInvolved from ThisFunctionCausedAPanic.cpp, line 455. Symbolicate the other frames you've got. This is a quick way to differentiate between something is wrong with THIS symbol vs something systemic is wrong. Yes, this is a “something systemic is wrong” situation. I was trying to reduce the amount of information for readers to wade through, but I am not getting useful results for any efforts at symbolicating the addresses on the back trace or the PC (program counter). ” dwarfdump will print the contents of a dsym file, which will either show that the symbols dwarfdump works on dSYM files, but apparently not on debug-builds-with-symbols-in-the-binary. As such, I rebuilt with separating the symbols into a dSYM file. dwarfdump provides what appears to be correct information for the symbols, but for a sanity check here is a blurb from the start

Thanks for your reply. If you are experiencing persistent issues, please consider submitting a bug report. To facilitate our investigation, would you be able to share a project demonstrating the problem? Additionally, please provide both dSYM files for comparison. We are eager to resolve this matter with your assistance. Please remember the software is still on beta. Albert Pascual
  Worldwide Developer Relations.