app-storeappstore-approvaliosxcode
I submitted my app to the app store and received the following warning (not error):
Too many symbol files – These symbols have no corresponding slice in
any binary [XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX.symbols,
XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX.symbols]
What caused this issue? How can I fix it? Will it create issues with crash reporting to Crashlytics?
Steps to analyze crash report from apple:
Copy the release .app file which was pushed to the appstore, the .dSYM file that was created at the time of release and the crash report receive from APPLE into a FOLDER.
OPEN terminal application and go to the folder created above (using cd command)
Run atos -arch armv7 -o APPNAME.app/APPNAME MEMORY_LOCATION_OF_CRASH. The memory location should be the one at which the app crashed as per the report.
Ex: atos -arch armv7 -o 'APPNAME.app'/'APPNAME' 0x0003b508
This would show you the exact line, method name which resulted in crash.
Ex: [classname functionName:]; -510
Symbolicating IPA
if we use IPA for symbolicating - just rename the extention .ipa with .zip , extract it then we can get a Payload Folder which contain app. In this case we don't need .dSYM file.
Note
This can only work if the app binary does not have symbols stripped. By default release builds stripped the symbols. We can change it in project build settings "Strip Debug Symbols During Copy" to NO.
More details see this post
This happens if you are including debug information of your libraries with the project archive but are not including binaries.
In the "dSYMs" folder you will see several files. If you run the dwarfdump console command on these files you will get a list of UUID strings:
dwarfdump -u MyFile.dSYM
I'm sure you will find some matching UUIDs from Apple's email.
To avoid this warning you need to include with your archive only the dSYM files of your application and not the libraries. For this you need to change the build configuration of the libraries to not generate a dSYM file. Just search for "debug information format" in configuration and change it from DWARF with dSYM File to DWARF only.
For example, in the screenshot below you will find the Stripe iOS framework.
Best Answer
Same problem occurred to me, and here is why this happening and the solution.
Short version: Redundant dSYM files are being produced due to improper project settings. In my case, the "project" consists of one major
.xcprojectand several CocoaPods projects, and theBuild Setting\Valid Architecturessetting of the latter one is more extensive than the former. Thus Xcode is producing redundant dSYM files for that pod projects and Apple detected those dSYM files is useless because the main project is set to a more constrained level.Bunch of bullshit version:
Go to
Window->Organizerand select your submitting version of archive andright click->Show in finderto locate that .xcarchive file. Then useterminalto navigate into the .xcarchive(it's a bundle like .app) and then to thedSYMsdirectory, rundwarfdump --uuid *to show the uuids of that dSYM files. Check whether the uuid(s) in the complaining email are in the list. The email says those dSYM files are redundant, so we should prevent producing them when building the archive.For me, I used AFNetworking and other 3rd party frameworks in my app, and they are added to the project(or workspace more precisely) via CocoaPods. I need to guarantee my app won't be installed on any device older than iPhone5s, so I set
Valid Architecturestoarm64only inBuild Settingof my project. In this case, I should also setValid Architecturessame for thePodproject targets(there may be several targets depending on how many frameworks you have added via Pods). By doing this,Podsproject won't produce the redundant dSYM files during the build process. After all thetargetsare set properly, go toProduct->Archiveto re-archive. You should check the uuid(s) of dSYM files again just in case.I hope I have myself understood :)