dsym file

Includes Symbols seems to indicate that symbols were generated from bitcode. I uploaded a binary with and without bitcode. With bitcode enabled, Includes Symbols turns to Yes and a dSYM is available for download.

We are seeing this too in our CI pipelines as well. As of Xcode 14, when uploading to iTC, no Apple generated dSYMS are being generated for download. We found that uploading the dSYM generated locally directly to Firebase was the way forward. As for Firebase not being able to process what you give it is odd. As long as the Bundle ID and MARKETING_VERSION are in sync, there should be no reason the mapping can't occur. I'd reach out Google directly and ask them whats up. I've found their turnaround and quality of support to be pretty good wrt Firebase.

There are two common causes for this:a UUID mismatch between the crash report and the .dSYMSpotlight failing to index your .dSYM (Xcode uses Spotlight to find the .dSYM based on its UUID)You can check the former using xcrun dwarfdump --uuid /path/to/your.dSYM. You can check the latter using mdls and mdfind. If the .dSYM has been indexed then mdls will show the com_apple_xcode_dsym_uuids attribute: $ mdls build/Debug-iphoneos/QTestbed.app.dSYM/ … com_apple_xcode_dsym_uuids = ( F3D98D35-B43B-3A29-BDF0-8186AF886EDB, 94BF1D20-2A89-3E96-81BC-C46330D6932F ) …You can then run a UUID through mdfind to confirm that Spotlight has the right info. For example: $ mdfind 'com_apple_xcode_dsym_uuids == F3D98D35-B43B-3A29-BDF0-8186AF886EDB' /Users/quinn/DTS Work iOS/Samples and Tests/QTestbed-GIT/build/Debug-iphoneos/QTestbed.app.dSYMShare and Enjoy — Quinn “The Eskimo!” Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

There’s no good way for folks here on the forums to address questions like this, because we don’t understand the circumstances associated with your app. However, I can provide some basic background. To start, you need to understand the different types of symbols that may be involved. I’ve collected a bunch of info on this topic into Understanding Mach-O Symbols. There is some symbolic information that you can’t strip: Symbols used by the dynamic linker for imports and exports The information used by the Objective-C and Swift language runtimes The best you can do there is to obfuscate your side of the equation. Apple doesn’t have tools for this. For Swift, you have some control above runtime information via the Reflection Metadata Level build setting. Beyond that, Apple is OK with you stripping as many or as few symbols as you want. It may result in you getting hard-to-understand crash reports, but you can fix those as long as you have the appropriate .dSYM file. We document the process for doing that

Hi eskimo,My library was integrated with a system extension developed by another team, I just want to debug it quickly without code change due to I already have dSYM and source code.

I'm getting the same when archiving a react native app. This started only after updateing to Xcode 16. The archive did not include a dSYM for the hermes.framework with the UUIDs. Is this warning can be ignored?

We need this so we don’t have to constantly enter our 2fa code. That is what the new App Store Connect api should be for but the download dsym method is missing. Please implement this Apple! Automation is key!

I have the same issue, mac pro with ssd and 16GB hangs more than 30 minutes with memory limit exceed on dSYM generation step. WIth XCode 9.3 all was fast and great. What to do??

Here's another thread with a discussion of this warning. That thread is long, and the number of folks asking about different facets of these messages makes that thread a bit unwieldily, so I want to reiterate one of my answers here for your clarity: This is a new warning in Xcode 16 where if you're missing a dSYM, Xcode lets you know in case you aren't expecting that — this is to reduce scenarios where you won't are able to fully symbolicating frames coming from your app's code in crash reports. In some cases, you may not have a dSYM, such as a closed source library from a vendor, and in those cases, the warning is safe to discard. — Ed Ford,  DTS Engineer

if you have Crashlytics in your project, there's this discussion in the firebase-ios-sdk repo: https://github.com/firebase/firebase-ios-sdk/issues/11471 Workaround fix that worked for some people including myself: The issue generally can be reproduced if you have an input file in run script from build output file and a binary SPM package in your program. Indeed both AWS and cardIO are binary SPM. We will make a feedback to Apple as well. Meanwhile to unblock you from build, you can shorten the dSYM path to ${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}/Contents/Resources/DWARF. Link to answer As always, double check that there are no undesirable side effects with the Crashlytics install, depending on your priorities and requirements.

I also I get the Validate error. So to do a test I tried to click on the Download dSYMs... and I get this error:Missing App VersionAn app record for “com.abc.Xyz” was found but a matching version for “1.0” build “100” was not. 😟

I ran into this same issue as well. It seems https is also supported the link just doesn't use it for some reason. You can right-click Download dSYM, copy the link, add the s to http, and navigate to that URL.

Yes, I have done all that. However, the option to set Debug Information Format to DWARF, rather than DWARF with dSYM is not a viable alternative, since it prevents the capture of crash reports by Crashlytics, HockeyApp, etc.

I get the same message in the console with XCode 16, but it does not crash the app on startup. So maybe the crash is not related to the message. The missing dSym does seem to make it impossible to symbolicate crash logs.