"Too many symbol files" after successfully submitting my apps
Solution 1
This happens if you are including debug information of your libraries with the project archive but are not including binaries.
- Open the Organizer window in Xcode
- Right-click on an archive that had this issue and select "Show in Finder".
- Right-click on the archive file and select "Show Package Contents"
-
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.
Solution 2
If you encountered this problem while using CocoaPods, add this to your Podfile:
post_install do |installer|
installer.pods_project.targets.each do |target|
target.build_configurations.each do |config|
config.build_settings['DEBUG_INFORMATION_FORMAT'] = 'dwarf'
end
end
end
It will set Debug Information Format to DWARF only for all your Pod targets only (not the main app target)
Solution 3
If you are using CocoaPods and your app is set to use arm64 only (i.e. there is only arm64 in your project's info.plist)
<key>UIRequiredDeviceCapabilities</key>
<array>
<string>arm64</string>
</array>
then you can try adding the following script in your Podfile to solve this issue.
post_install do |installer|
installer.pods_project.targets.each do |target|
target.build_configurations.each do |config|
config.build_settings['ENABLE_BITCODE'] = 'NO'
config.build_settings['ARCHS'] = 'arm64'
end
end
end
AND
set all your projects' targets (not the targets in Pods) to arm64 only
CocoaPods Github issue reference
Solution 4
I have this issue due to the project has valid architecture arm64 where the CocoaPods targets have valid architecture arm64, armv7 and armv7s.
To check which target has which valid architecture follow following steps
- In Xcode -> Window -> Organizer
- Select the archive and Reveal in Finder
- On .xcarchive file, Show package content
Open terminal and give path of dSYMs folder.
Enter command
dwarfdump --uuid *
and it will show list of UUIDs with valid architectures.
The UUID will match with Apple's warning email
The main project and cocoa pods target suppose to have same valid architecture. By doing this, it will solve the issue.
Solution 5
Worked for me by enabling bitcode - it was off before
Enable Bitcode - Yes
Related videos on Youtube
Jim Barber
Updated on April 29, 2020Comments
-
Jim Barber almost 4 years
I downloaded Xcode 6 GM and submitted two Swift apps to the app store today. Both passed all pre-upload verification and all the other stuff they had to pass and were successfully submitted. But then I got two emails from Apple... one for each program and they both said this:
Dear developer,
We have discovered one or more issues with your recent delivery for "xxxxxxxx" (my app name removed). Your delivery was successful, but you may wish to correct the following issues in your next delivery:
Too many symbol files - These symbols have no corresponding slice in any binary [1431D977-72BC-308F-AB71-71529F25400B.symbols, 158C72A7-98AC-3F07-B2BE-88427591B413.symbols, 44973EAC-563E-340C-B549-55A5014A68BA.symbols, 678BF06F-0C3D-3A09-BFBF-699C7079FECD.symbols, 90907DDB-0400-38ED-BB5F-0C12333C0624.symbols, 93B79949-5757-374A-97B9-825AE1A61B7D.symbols, ABA05220-4FB0-397F-AFBB-08774A82F4CA.symbols, AD70F02A-4422-32B8-8C40-CF9B45A2CCC6.symbols, B0CC9F7D-C542-3E18-A518-B28B7ECABE80.symbols, BF6A4C3B-6FA5-3C51-8404-19C2F132458D.symbols, C9D6E078-8E2A-39D9-8DEE-476916A69CEE.symbols, CF5320DF-AB31-3845-BAD5-F6E51045D396.symbols, D4967AA3-8FB0-3712-B0DE-7F4144AF8F4B.symbols, D813B314-AD37-31D4-B675-442052994495.symbols, DF42A13F-08D8-3E71-B221-FC357E0B60F5.symbols, F5F636C2-F0E0-3CA7-8F7D-C49A36CD5C65.symbols]
After you’ve corrected the issues, you can use Xcode or Application Loader to upload a new binary to iTunes Connect.
Regards,
The App Store team
I'm going to guess that really has nothing to do with me or my apps... and it is just a quirk of day one Swift app submissions? Both apps are still sitting in "Waiting for approval" mode. I certainly can't think of anything I could change to make what they said go away! Anyone else submit a Swift app yet and get that response? Think I should just ignore it and wait to see what happens?
-
Dehli over 9 yearsMine said that and
Invalid Swift Support
. Any idea why I might get this? I'm using the latest Xcode. -
yudun1989 over 9 yearssame issue here, and my app can not submit for review.because of this issue.anyone solved?
-
dandoen over 9 yearssame issue here. submitted for review anyway.. let's see what happens :)
-
Jim Barber over 9 yearsBoth of my Swift Apps were just approved to the App Store... so I guess I worried for nothing! Whew... :)
-
-
Louis Hong over 9 yearsI really hope you would be more detailed.... I have no idea what checkbox or popup you're talking about. Maybe a screen shot?
-
Louis Hong over 9 yearsgyazo.com/6d7bb2035979cb75253ba92a40e8d898 I think I see it, it's this one
-
Markus Rautopuro over 9 yearsYes, but this will strip all the symbols from the package, and therefore you won't receive symbolicated crash reports? (Do they even provide symbolicated crash reports in App Store apps now with TestFlight?)
-
JConway over 7 yearsThis is not a valid solution to the problem. This is avoiding the symptom, not addressing the issue. See Mikhails answer for a description on how you are uploading symbols you don't need. This answer prevents uploading any symbols, thus breaking crash symbolication via iTunesConnect
-
user924 almost 6 yearsDON'T do that, if you do you won't be able to analyze you app on App Store for crash errors
-
Cesar Rodriguez over 5 years@wzbozon Yes, I ask just to double check. Because after I did it, Crashlyticts stop working. Thanks!
-
Stan over 5 yearsCrashlytics should continue working for your app as this script changes build settings for pods only.
-
Denis Kutlubaev over 5 yearsI agree. But you won't see reports for pods. One could also set DWARF with dSYM File for some pods only, for example development pods.
-
airowe over 5 years@Stan are you saying that Crashlytics will keep working? Cesar Rodriguez seems be saying it will not work.
-
firebear over 5 yearsThis solved it for me. Don't forget to
pod install
-
shim over 4 yearsPresumably you should include arm64e too now, no?
-
Jon over 4 years
dwarfdump -u *
in the folder to see all UUIDs -
Serj Rubens over 4 years@Jon ooooh why i see it after i made one by one? :) anyway thanks!
-
Ariel Bogdziewicz over 4 yearsI think it explains the best what is going on. I have these warnings only about libraries with armv7 architecture because my project is built only for arm64. Question remains if I should add armv7 to the project or remove it from Pods.
-
Ariel Bogdziewicz over 4 yearsstackoverflow.com/a/49063850/3293172 iOS 11 dropped support for armv7 and armv7s so there is needed only arm64 if you have deployment target >= iOS 11.0.
-
Benjamin Wen about 4 yearsWorks for me. No such issue after uploading packages.
-
Eugenio about 4 yearsWill removing the dSYM files means any crashes related to 3rd parties will not be symbolicated anymore on Crashlytics (or any other crash reporting tool)?
-
Mattia Lancieri about 4 yearsIf you use firebase \ fabric, however, the dsym files should be used to view the crash logs on the site. Do they still work with this change?
-
cybergen almost 4 yearsI'd include arm64s for the simulator. It'll be removed automatically for release builds.