dsym file

Thanks Edford, but this page you mention doesn’t mention how to get the dsyms from Xcode cloud and there is no button to download from App Store Connect on those crash reports. https://help.apple.com/xcode/mac/current/#/devef5928039 can you point me to something that is updated for Xcode cloud?

I just switched to Xcode 16 and a new build machine and I’m getting the warning about missing dsyms. I see that they are in the archive but the UUID doesn’t match what App Store Connect is expecting. Is there a way to update App Store Connect with the new UUID?

I also just ran into this issue. I uploaded a build with Bitcode enabled on March 27th and there is no Download dSYM link in App Store Connect for the build although App Store Connect does say the build included symbols. Very frustrating as I am now unable to symbolicate any crashes from this version of my app.

For the record, I am answering my own question. Yes, 'atos' was the correct tool to use. The key was realizing that the '.archive' file was needed by 'atos'... In addition to the console text shown above, there was also this snippet: ... Binary Images: 0x10a062000 - 0x10a325fff +[devProdID] (2.2.3 - 3302) <9248A949-D5CB-3C44-924B-2A9403061E7B> /Applications/AppXYZ.app/Contents/MacOS/AppXYZ ... So the actual command which achieved the desired result was: atos -arch x86_64 -o /Users/steve/Library/Developer/Xcode/Archives/2021-09-10/AppXYZ 9-10-21, 9.05 PM.xcarchive/dSYMs/AppXYZ.app.dSYM/Contents/Resources/DWARF/AppXYZ -l 0x10a062000 0x000000010a069107

First things first, have you verified that the .dSYM has the matching UUID? QA1765 How to Match a Crash Report to a Build shows the steps. Share and Enjoy — Quinn “The Eskimo!” Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

but there’s no way to specify file and line number to the log(…) function Right. The system log implementation does not log file and line numbers in the traditional way. Rather, the log ends up including: The Mach-O UUID of the caller — If you look at the C API, you’ll see that under the macros there’s a dso parameter that is effectively a pointer to the mach_header[_64]. The offset into that Mach-O — It finds the caller by walking up the stack, and then calculates the offset from the dso. This allows log clients to recover the file and line info from a .dSYM, in much the same way as symbolication [1]. The primary motivation for this is space saving, in your program, the transient log buffers, and the final on-disk log. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] See Adding Identifiable Symbol Names to a Crash Report.

I get the same issue and i have solved it now. i'd like to share my solution.command line below will result in xcarchive missing BSCymbolMaps and dSYMs${xcodePath}/xcodebuild -workspace ${workspace} -scheme ${scheme} -configuration ${configuration} -sdk ${sdk} -archivePath ${archive_path} archive CONFIGURATION_BUILD_DIR=${build_dir}command line below will solve the problem${xcodePath}/xcodebuild -workspace ${workspace} -scheme ${scheme} -configuration ${configuration} -sdk ${sdk} -archivePath ${archive_path} archiveI find adding a buildingsetting CONFIGURATION_BUILD_DIR=Path will change the others buildSetting variables such as DWARF_DSYM_FOLDER_PATH, i guess it will lead the missing of BCSymbolMaps and empty dSYMs folder in xcarchivecheck DWARF_DSYM_FOLDER_PATH buildsettings value maybe helpyou can see DWARF_DSYM_FOLDER_PATH value by excute command line xcodebuild -workspace APP.xcworkspace -scheme APP -showBuildSettings in your project root path.

It's all done via a script, but the basic gist is: xcrun xcodebuild archive -archivePath MyFramework.xcarchive -scheme MyFramework xcrun xcodebuild -create-xcframework -framework MyFramework.xcarchive/Products/@rpath/MyFramework.framework -debug-symbols MyFramework.xcarchive/dSYMs/MyFramework.framework -output MyFramework.xcframework ditto -c -k --rsrc --keepParent MyFramework.xcframework MyFramework.xcframework.zip The zip file is attached to a GitHub release, and I download it in the app project, expand it and link to it as normal. I can see looking at this how the signing might be a bit off by reaching into the xcarchive directly, rather than exporting the framework first. I might try using xcodebuild -exportArchive prior to creating the XCFramework, and see if that helps.

This may be an old question, and there may be recommendations against rolling your own solution, but for those who prefer to write their own solution, I wanted to share mine. To write your own crash reporter you need to capture signals and exceptions. To capture signals, use a handler in this format: signal(SIGINT) { _ in var threadStackTrace = _ = Thread.callStackSymbols.map({ threadStackTrace.append(($0)n) }) } This will build a string representing the lines of a stack trace. SIGINT is just one of the signals that you need to capture. There are 14 other signals that I capture in my crash reporter. You'll need a separate handler for each signal. Here are a few other signals I capture: EXC_BREAKPOINT, EXC_CRASH, EXC_BAD_ACCESS, EXC_BAD_INSTRUCTION, SIGABRT, SIGKILL, SIGTRAP, SIGBUS, SIGSEGV, SIGHUP, SIGTERM, SIGILL, SIGFPE, SIGPIPE. There may be others that should be handled. In Xcode, 'Jump to Definition' to see other signals. You also need to capture uncaught exceptions. You can do that with: NSSetUncaught

Hi,Where exactly do you go to disable CLANG_ENABLE_MODULES and enable dSYM creation in xCode? Any help to point me there will be greatly appreciated it, I have been trying to get rid of these warnings for a long time now.Also, if these warnings don't go away. Will Apple still accept the App for to publish on the App Store?Thanks!