dsym file

Even I am down to one file in .dSYM that shows reference as mentioned by Vikram. Is there any solution for how to fix this ?

I can't speak to why your Release build isn't working, but that is something you should probably look into.You can check to see if your Debug-iphoneos folder has the matching binary/DSYM as is installed on the device. Take a run in Instruments and look at the UUID for your binary in the File->Symbols... sheet. Then, in Terminal, go to your Debug-iphoneos folder, and run: otool -l <YOUR_APP_BUNDLE>/Contents/Resources/DWARF/<YOUR_APP_BINARY_NAME> | grep uuidYou should see one or more UUIDs printed out. If one of those matches what you saw in Instruments, then Instruments should be able to use that dSYM if you locate it in the Symbols sheet.You can also check if Spotlight can find the dSYM. From the Terminal: mdfind <YOUR_UUID_HERE>You should see the location of the dSYM. If not, your Spotlight index might need a rebuild.If this doesn't help you along, you should file a radar with as much info as you can.

Pretty much the same issue here . Ensure that the archive's dSYM folder includes a DWARF file for EzCCS.app with the expected UUIDs

After spending several hours profiling lldb, I have identified the reason behind the high CPU usage and slow app launch and breakpoints. It turns out that a custom xcconfig file was disabling dSYM for the Debug build. However, once I restored the dSYM in the Derived Data Xcode, both lldb and our app started up quickly again.

You have the binary images now at the bottom of your crash log but your code and your 3rd party code is still not symbolicated. You will want to do yourself a favor and symbolicate the crash log. This will allow you to see what execution paths of your code may be involved with the issue. If the correct symbol files are on your system, you can symbolicate a crash log by dropping the crash log into the Device Logs section of the Xcode Organizer. Otherwise, if worst comes to worst you can symbolicate your crash log by hand if you have the dSYM files. This process is described here. A brief example using atos would look like this: # Using 0x10039c000 as your load address: 0x10039c000 - 0x104e67fff Runner arm64 <09637c1ad9b5338382390b2d3f090727> /var/containers/Bundle/Application/13D70FFF-A12B-45D6-8490-25A7FD7ECC03/Runner.app/Runner ---- # Using 0x00000001003a5ac0 as the address to symbolicate from thread 12 of your app: Thread 12 name: Dispatch queue: com.apple.avfoundation.videodataoutpu

I'm getting a similar error when validating my package after upgrading to Xcode 16. Error: Upload Symbols Failed The archive did not include a dSYM for the LofeltHaptics.framework with the UUIDs [8274DE6D-513B-3DDA-BE9F-C6106B01CB0D]. Ensure that the archive's dSYM folder includes a DWARF file for LofeltHaptics.framework with the expected UUIDs.

It is challenging to pinpoint the exact issue without additional information about your project or a specific project demonstrating the problem. Could you please provide details about your framework or the third-party framework you are using? How was it built, and what are the configuration and settings in the project? A comprehensive view is always beneficial, but I will attempt to offer some potential solutions. However, providing a project illustrating the issue would be more advantageous for such types of errors. The error message indicates that there are two issues with the archive being uploaded to App Store Connect: Invalid Executable: The executable AppInvokeSDK.framework contains Bitcode. App Store Connect does not allow frameworks that contain Bitcode. Bitcode is a way of compiling Swift and Objective-C code into an intermediate format that can be optimized later by Apple's servers. Missing dSYM for AppInvokeSDK.framework: The archive did not include a dSYM for AppInvokeSDK.framewo