dsym file

Same issue here. It seems as if appstoreconnect currently attributes incorrect UUIDs to dsyms generated from bitcode enabled build archives. One way to solve this (and the only one I know of) is to rename the internal UUID of the dsym that corresponds to the binary image of the stack frame that isn't symbolicated. In most cases this is your app's binary image. What you can do is either manually rename it using the already mentioned excellent article on medium, or automatically using the following tool: https://github.com/schmittsfn/dsymrename You have to be absolutely sure, however, that the dsym you are renaming corresponds to the build Crashlytics is requesting (for bitcode builds these are the dsyms generated on appstoreconnect)! Failure to do so will most likely lead to the warning on Crashlytics being silenced and the stack frame being unintelligible.

We ended up filing a support request with Apple on this, and they responded that the issue is resolved by building with Xcode 10.2. It is referenced in the release notes:https://developer.apple.com/documentation/xcode_release_notes/xcode_10_2_release_notesUnfortunately our latest build, built with Xcode 10.2.1, still doesn't have a download dSYM link.

I have a similar problem as described in this thread. When building a Debug version my dSYMs all generate correctly and work properly with Firebase Crashlytics. However when I perform a Release Build there is a problem with the generation. In my archive one of the files is missing, specifically the app.debug.dylib file. I verifed the debug format, changed Strip settings, etc without any fix. Any ideas of how to solve this problem?

I guess it need .dsym on your disk.

In all instances I’m aware of, apps that are getting the UIWebView usage warning are in fact linking to the UIWebView framework. It may be in third party libraries or frameworks. Please check again what your app and its libraries link against. You can do so by running the grep command in Terminal. For example, Open Terminal. Type the following on the command line to change to the directory where your application binary is: cd ~/Library/Developer/Xcode/Archives// To search for UIWebView use the following command: grep -R UIWebView * This should give you a list of files that contain a reference to UIWebView. From that list you should then be able to determine where the UIWebView reference is. To make this a bit more concrete, the other day I created a test app named SingleViewApp and archived it, so this is what I did to check for the UIWebView: % cd ~/Library/Developer/Xcode/Archives/ % ls 2019-08-26 2020-03-09 % cd 2020-03-09 % ls SingleViewApp 3-9-20, 11.38 AM.xcarchive SingleViewApp 3-9-20, 11.41 A

Did you figure out where these dSYMs are during build, or how to get them?

FIled a radar bug: 25506150 . I can confirm our itunesConnect account has: Include Symbols: On. When I download the dsym logs from itunesConnect, it shows symbols as hidden. This is a troubling bug for us as we have bitcode enabled in our app. Any ETA from Apple on the fix as it seems like it is a long standing problem for many developers.

Bumping this. I seem to have the same issue. Neither for builds done via Xcode Cloud, nor for builds uploaded via Xcode (15) directly can I find the dSYM's anymore. They're not in the Build Metadata and I also cannot seem to download them via Fastlane - that doesn't find any dSYM's either.

In all instances I’m aware of, apps that are getting the UIWebView usage warning are in fact linking to the UIWebView framework. It may be in third party libraries or frameworks. Please check again what your app and its libraries link against. You can do so by running the grep command in Terminal. For example, Open Terminal. Type the following on the command line to change to the directory where your application binary is: cd ~/Library/Developer/Xcode/Archives// To search for UIWebView use the following command: grep -R UIWebView * This should give you a list of files that contain a reference to UIWebView. From that list you should then be able to determine where the UIWebView reference is. To make this a bit more concrete, the other day I created a test app named SingleViewApp and archived it, so this is what I did to check for the UIWebView: % cd ~/Library/Developer/Xcode/Archives/ % ls 2019-08-26 2020-03-09 % cd 2020-03-09 % ls SingleViewApp 3-9-20, 11.38 AM.xcarchive SingleViewApp 3-9-20, 11.41 A

For everybody who need quick fix... I fix this problem with this solution: Open Organizer in XCode menu - menu>window>organizer Select your IPA build and with right mouse click select show in finder On generated file with right mouse click select show package content Comprim DSYM directory to .zip file and move him outside the package for use tham, where you need it. Enjoy ;)

In all instances I’m aware of, apps that are getting the UIWebView usage warning are in fact linking to the UIWebView framework. It may be in third party libraries or frameworks. Please check again what your app and its libraries link against. You can do so by running the grep command in Terminal. For example, Open Terminal. Type the following on the command line to change to the directory where your application binary is: cd ~/Library/Developer/Xcode/Archives// To search for UIWebView use the following command: grep -R UIWebView * This should give you a list of files that contain a reference to UIWebView. From that list you should then be able to determine where the UIWebView reference is. To make this a bit more concrete, the other day I created a test app named SingleViewApp and archived it, so this is what I did to check for the UIWebView: % cd ~/Library/Developer/Xcode/Archives/ % ls 2019-08-26 2020-03-09 % cd 2020-03-09 % ls SingleViewApp 3-9-20, 11.38 AM.xcarchive SingleViewApp 3-9-20, 11.41 A

Seems like it's working today, the missing dSYMs are back

This is caused by Python version mismatch between LLDB and scripts inside kernel's dSYM. Python scripts inside your dSYM require Python 2 but Python 2 support has been removed from newer LLDBs. To solve the problem you will have to install older LLDB/Xcode that still has Python 2 support.