dsym file

Same issue here, Xcode 16 build on previously working Xcode 15. It looks like Xcode 16’s settings conversion is clearing the setting, or has changed the default setting for Debug Information Format. I’ve found the following removes the error and allows distribution. Go to your target's Build Settings and enter debug information format in the search field. For Debug, Release and Test, make sure the setting is DWARF with dSYM File. Now Clean Build Folder and then Archive.

Since I rely on Apple to sign the apps, I'm assuming that nothing local can be used. This is only true if you use bitcode. If you don’t use bitcode then the .dSYM files that you create locally, that get embedded in your Xcode archive when you do a Product > Archive, are valid for your App Store app. The significant change here is that Xcode 14 has effectively nixed bitcode as a concept. See the comment in the Xcode 14 Release Notes. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

If I archive only using Xcode Cloud (with the option to include symbol enabled), can the Xcode Organizer show symbolicated crash logs for app builds that are more than 30 days old (the archive availability window)? For example, a crash for an app version released 6 months ago. This is where you should treat Xcode Cloud as separate from what happens after you submit a build to App Store Connect. Xcode Cloud can do an archive your app, and then additionally submit that build to the App Store according to options you configure. You could do both of those at your desk as well, with the same options. So if you ask Xcode Cloud to upload your build to the App Store with symbols, you'll get automatically symbolicated crash reports in Xcode Organizer, the same way as if you submitted the build to the App Store by archiving at desk in Xcode and submitting from your desk, with the option to include symbols enabled. After this point of submitting to the App Store, you're then in the world of supporting services the App S

I've faced the same exact issue. Here how it looks from a Fabric report file:Crashed: com.apple.main-thread 0 My App 0x100ddb618 $S13My_App20SearchViewControllerC05tableD0_14didSelectRowAtySo07UITableD0C_10Foundation9IndexPathVtF () 1 My App 0x100ddb67c $S13My_App20SearchViewControllerC05tableD0_14didSelectRowAtySo07UITableD0C_10Foundation9IndexPathVtFTo () 2 UIKit 0x18cef2bb4 -[UITableView _selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:] + 1352 3 UIKit 0x18cf9b7f4 -[UITableView _userSelectRowAtPendingSelectionIndexPath:] + 268 4 UIKit 0x18d049b3c _runAfterCACommitDeferredBlocks + 292 5 UIKit 0x18d03cef0 _cleanUpAfterCAFlushAndRunDeferredBlocks + 288 6 UIKit 0x18cdce54c _afterCACommitHandler + 132 7 CoreFoundation 0x1838a1edc __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 32 8 CoreFoundation 0x18389f894 __CFRunLoopDoObservers + 412 9 CoreFoundation 0x18389fe50 __CFRunLoopRun + 1292 10 CoreFoundation 0x1837bfe58 CFRunLoopRunSpecific + 436 11 GraphicsServices 0x18566cf84 GSEventRu

I'm in almost the same situation. Even though Includes Symbols says Yes on the iTunes Connect build page, my crash reports don't symbolicate in Xcode. The UUID is different on the crash reports than the build and dSYM file (presumably because the crash UUID refers to the bitcode build), so I'm stuck with a bunch of crashes I would love to debug and hex memory addresses. Super frustrating.Some people over on this thread report crash logs for some apps symbolicate while others don't. You might want to file a bug report with Apple and then post the issue number there. mychrisdangelo from Apple seems to be monitoring the issue.

Thanks @edford. My issue is that (my app generated since 2007 by Objective C ) on old iOS (prior to iOS 15.x), I can find the crash file with XXXX.crash or XXXX.ips.beta, and update the name to .crash, download .dsym file to parse the crash file by Xcode, since iOS 15.x, at least on my team side, there is no XXX.crash or xxxx.ips.beta file when crash occurred. attached file was on iOS 15.x device when app was crashed, I have no idea how to take old school way to parse those crash log. if I take the old school to change the extension name from .log to .crash Xcode does not accept those file at all when I drag to device logs panel. Best regards.

Hi eskimo, Sorry for hijacking this ticket but I have a counter question to your response. _`Since I rely on Apple to sign the apps, I'm assuming that nothing local can be used. This is only true if you use bitcode. If you don’t use bitcode then the .dSYM files that you create locally, that get embedded in your Xcode archive when you do a Product > Archive, are valid for your App Store app. The significant change here is that Xcode 14 has effectively nixed bitcode as a concept. See the comment in the Xcode 14 Release Notes.`_ My Question is that We have the requirement of keeping bitcode enabled until a SaaS service we are using comes up with an enhancement to Apple's change. Can you please explain why the local .dSYM won't work if bitcode is enabled? Is there anything we can do to successfully symbolicate our crash reports with Enable bitcode and Xcode 14 as we don't get the option to download them in iTunes Connect now?

I tried Enable Debug Dylib Support = NO. At the beginning I saw that the message was gone and I was really happy, but then I tried to make some crashes but no dsym files were uploaded in Firebase. I switched again in Yes and I saw the message again, but after that when I made some crashes, I saw the logs in Firebase. I cannot say that I have a clear answer or I realised exactly what happened, but now it's working. In all these tries I run my app from Xcode of course, but sometimes I just run my app directly from the phone. I don't know if this helped the situation for this thing to unstuck. I hope that maybe someone will get some help from all these and make it work

Any idea how to download it when the build done from Xcode cloud? @kassa11, you should download the final archive from Xcode Cloud. See Download and archive build artifacts. We used a no-code platform to build our app. How would we download it without access to Xcode? @FeelGoodMealsNC, that is between you and the vendor of your no-code tool, as they should provide you with the complete set of build artifacts, including all available dSYM files. However, I suspect the reason you're inquiring about this information here is that you're receiving a warning when uploading your app to the App Store. If that's the case, then you'll want to see this other thread. Note that Firebase is a very common library in the iOS developer community, but if it has any closed source components (I do not know since it's from a vendor and not from Apple), then a dSYM may not exist if the author of the library does not wish to make such symbol information available to its clients. —Ed Ford,  DTS Engineer

Well in my case, just now, I was using one of my own frameworks (built through Carthage). When I stopped having Carthage build it, and just dropped the framework project into my project's workspace, I got past this error.Note that I was still using other Carthage built frameworks, just my own was freaking out for some reason?Additionally, once I had my Framework Project in my Workspace, I adjusted it's framework search paths to point to an absolute filesystem location of the Projects Carthage's Build/iOS (recursive) folder.--- Later ---nevermind, I had to re-archive the app and now the error is back again, but for a different framework I don't control. =(---- Later Still ----Ok, I got it! For me anyway, I needed to remove the dSYM files that Carthage generated from the Apps Resource Bundle.