dsym file

FWIW, in another thread on the same issue, a user suggested going to Build Settings -> Build Options -> Debug Information Format, and changing the selection to DWARF only for both the debug and release build, and then change it back to DWARF with dSYM File. I haven't uploaded a new archive yet to test, but after making that change, the following lines are added to project.pbxproj. Given that DWARF with dSYM was originally selected and these lines were added only after changing to DWARF and back, it seems that XCODE 16+ fails to add those options to the project file

Hi all, I came across the same issue when adding -debug-symbols to xcframework, which resulted with following error: error: the path does not point to a valid debug symbols I resolved it by using the absolute path when referencing the dSYM/BCSymbolmap files So instead of using the relative path when referencing eg dSYM file xcodebuild -create-xcframework ttttt -framework myFramework-iOS.xcarchive/Products/Library/Frameworks/myFramework.framework ttttt -debug-symbols myFramework-iOS.xcarchive/dSYMs/myFramework.framework.dSYM ttttt ... I would use the absolute path xcodebuild -create-xcframework ttttt -framework myFramework-iOS.xcarchive/Products/Library/Frameworks/myFramework.framework ttttt -debug-symbols ~/myFolder/myFramework-iOS.xcarchive/dSYMs/myFramework.framework.dSYM ttttt ... This way, the dSYM was properly integrated into final xcframework. Hope this helps somebody.

You should stick to Xcode's default build settings here: GCC_GENERATE_DEBUGGING_SYMBOLS: Yes DEBUG_INFORMATION_FORMAT: DWARF for Debug builds, and DWARF with dSYM for Release builds For a release build, this combination means that you'll still have symbols, but they are extracted to a separate bundle called a dSYM file. This way, your app is not consuming more space than it requires when released to your customers. The benefit to you for keeping symbols enabled is that you'll be able to debug the app — without this, you'll have less information in the debugger when working with your Debug build, and you'll be unable to symbolicate any crash reports coming in from your customers.

Sorry, this Xcode16 just sucks. I've lost another half a days fiddling around with no luck, I just don't know what to do, and where. The project is big and in order to recreate the functionality, and the lldb bug, I have to build a whole new project, which will end up resembling the original one, minus some functionalities, so I dropped this route. The issue appears in one of the projects's internal static library. Now, I pause the execution at some breakpoint, run the po command and promptly get the Couldn't realize Swift AST type of self. Then I run swift-healthcheck, check the health log file, find the error below and conclude that the issue is in the static lib XXX. SwiftASTContextForExpressions(module: XXX, cu: AllParts.swift)::LoadOneModule() -- Missing Swift module or Clang module found for XXX, imported via SwiftDWARFImporterDelegate. Hint: Register Swift modules with the linker using -add_ast_path. Then I added -add_ast_path on the Other Linker Flags of the final executable, and now I get an

And what is interesting, the dSYM file itself is corrupted. It contains all of those extra characters.What extra characters are you talking about? I looked at your screen shot and I don’t see anything anomalous. Are you referring to the _$S13 stuff? Share and Enjoy — Quinn “The Eskimo!” Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

I just created a small test project with a standard framework (from the Framework template), with no other changes to the default template. From there, I configured the project to build as an XCFramework. As part of the -create-xcframework command, I added the -debug-symbols option so that the original dSYM from the framework archive gets copied in. When I then throw this XCFramework into a new test app that imports my framework, and archive that, the app's archive automatically contains the dSYM file. If you run the same test, what happens? — Ed Ford,  DTS Engineer

[quote='821969022, Fat_Panda, /thread/772077?answerId=821969022#821969022, /profile/Fat_Panda'] How can I find the UUID in my dSYM file? [/quote] Using dwarfdump. Adding identifiable symbol names to a crash report explains the exact syntax. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I'm also getting the same problem. The dSym files seems to be there as well, but navigating to it doesn't do anything. Also Instruments is showing a lot of leaks, but when you run the same app on a physical device, there's no leaks shown. So right now it looks like Xcode 12 Instruments doesn't play nicely with the Simulator, which obviously is a massive problem!

The key thing to do is make sure to download the archive builds for any version that you distribute, either through the App Store, or if you distribute through other means for testing or enterprise workflows. That way, you have the dSYM files locally — Xcode Cloud stores your archives for 30 days. Download and archive build artifacts covers these details. — Ed Ford,  DTS Engineer

Anyone found a fix for this? We also experience this problem. I just cannot build and run on either a simulator or device using Xcode 16. The app crashes on launch with the following stacktrace: #0 0x000000010595cf30 in __pthread_kill () #1 0x0000000104d9b124 in pthread_kill () #2 0x000000018016c4ec in abort () #3 0x0000000104b82f18 in abort_could_not_find_entry_point___debug_dylib () #4 0x0000000104b82744 in getDebugDylibEntryPoint () #5 0x0000000104b81f98 in __debug_blank_executor_main () #6 0x0000000104dd5410 in start_sim () #7 0x0000000104eda154 in start () And the following warning: warning: (arm64) /path/to/executable empty dSYM file detected, dSYM was created with an executable with no debug info.

I should disable bitcode in my app (I’ve seen guidance on that). I’m not DTS expert on bitcode, nor do I work for App Review so I can’t make definitive statements on their behalf, but my take on this is that: If App Review follows historical patterns, they will at some point require you to submit with the iOS 16 SDK. To do that you have to use Xcode 14. And, per the releases notes, that doesn’t do the bitcode thing. Given that, you might as well get a head start on the bitcode-ectomy. Then, the local dsym files can be used with Crashlytics? I can’t offer any insight in to third-party crash reports — honestly, I think you should avoid them, for reasons I outline in Implementing Your Own Crash Reporter — but I will say that, if you don’t use bitcode, the .dSYM files in your Xcode archive are sufficient to symbolicate your app’s symbols in any Apple crash reports you get. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com