dsym file

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

I have the exact same Problem with Xcode 8.2.1.It would be awesome if an Apple Engineer could help us out. Where do we have to put the dSYMs files? We use a build server to submit the binaries to iTunesConnect and all developers get unsymbolicated crash reports in Xcode. We would like to use it as our main crashreporter tool, but it isn't usable as it is. Please help us out or fix it in an upcoming release.

any update on this? Firebase and Crashlytics expect a dSYM file that does not exist. I've tried all combinations of 'strip' 'dont strip' and 'upload... to receive symbolicated...' and not checking 'upload... to receive symbolicated' when distributing my application to itunes from Xcode.yes, DWARF with DSYM is turned on in my build settings.Also the download debug symbols that appears in Xcode under Window > Organizer > Archives does not find any Dsym locally - which I can confirm by right-clicking the build, saying 'show in finder', then right clicking my abc.xcarchive and saying 'show package contents' the folder that says 'dSYMs' is always empty.Yes, I have also tried disabled 'bitcode', so that there should be no 'app thinning' related issues.Yes, I am using the absolute latest version of Xcode: ersion 11.1 (11A1027)

Do you think the reason I am unable to further symbolicate the .ips file is because I do not have the correct .dSym file? I don’t know, but this is one of the most common causes of such problems. Can you tell me how to use dwarfdump to see if I have a .dSYM with the right UUID and how to use mdfind to see if it is visible to the symbolicator and what to do if it is not? That information is in Adding Identifiable Symbol Names to a Crash Report. Open that page and search for dwarfdump for the first and mdfind for the second. Where is the required UUID? If you look in the above-mentioned doc, there’s an image that illustrates this in the discussion of mdfind. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

OK, the first step here is to make sure that you have a .dSYM file that matches the UUID of your executable from the crash report (c89cb8e1714435b6a04da699b3bc9b2e). You can confirm this with dwarfdump, as discussed in Technote 2151 Understanding and Analyzing iOS Application Crash Reports. Share and Enjoy — Quinn “The Eskimo!” Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

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. For those developing or using libraries that are statically linked, I was not able to reproduce this warning using either the example XCFramework attached in the bug reports noted in this thread, or by doing some simple testing with libraries that I know are popular in the iOS developer community and also statically linked. For the purposes of these tests, I'm creating a brand new Xcode project, adding the library through a Swift package, and making at least function call into the library so that it doesn't appear as dead code that can be eliminated as a release optimization. For these tests, the Xcode archiv

First - Thank you. Your reply is bery much appreciated.Unfortunately, they did not supply a list of devices or OS versions. Their entire response is below, minus the crash log. They suggest symbolicating the crash log, but since I used PhoneGap Build to create the .ipa file, I don not have a .dsym file to do that with. I know that the app works in airplane mode, so networking is not an issue. If those are my only options, it looks like I have no avenue to pursue to resolve this.

Xcode's warning here is so that you're aware that you may not receive fully symbolicated crash reports that involve code paths through that library. It's also just a warning so that you're aware, but does not impede any runtime functionality in your app. Please see my reply in another thread for a more in-depth discussion. In particular, I said: Your library vendor may have intentionally made that choice to not include a dSYM for proprietary SDK reasons, and that's a choice that's up to them. If you have any further questions about Firebase not providing you with dSYM files, please contact their support. —Ed Ford,  DTS Engineer

As far as I know, it’s the nature of a static framework to not contain symbols since the framework will be embedded in the final app binary, and the symbols should then be generated. The heart of a static framework is a static library, which essentially is a bag of unlinked object files. It's your choice whether or not to include symbols, but if you do, they will be part of the object files, and not a dSYM. When the final app links a static library, this information is then extracted and combined into the dSYM file for the app as if those object files were their own. However, when testing the Validate function of the Xcode 16 deployment process, our users are receiving a warning that says the framework does not contain symbols. Can you be specific about the exact text in the warning message? A screenshot of the message is welcome too. — Ed Ford,  DTS Engineer

Exact same problem here. I thought it might be because I am using Carthage and was not copying my dSYM files into my product. So I fixed that issue, per the carthage docs, No love still. Get the same error.Ah! When I uncheck the `Include Bit Code` option as mentioned here everything is fine. So I am going to assume that the problem lies in one of my dependant frameworks being complied without Bit Code enabled.