Mapbox-gl-native: Received “Too many symbol files” warning from Apple on uploading iOS app

[brblakley]

Mapbox iOS SDK 3.6.4
CocoaPods 1.3.1
Xcode 9.0
macOS 10.12.6

When I uploaded my app to the App Store via Xcode, I got an email from Apple:

… 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 [26992B3B-007F-3DA0-85BC-94D5B480E5D1.symbols, 2DC125FA-D463-3D81-AB23-5FD069BE495B.symbols]
…

I ran dwarfdump --uuid * on the archive’s dSYM folder and got:

…
UUID: 434BADDC-6773-330F-942D-4F25B9129775 (armv7) Mapbox.framework.dSYM/Contents/Resources/DWARF/Mapbox
UUID: 26992B3B-007F-3DA0-85BC-94D5B480E5D1 (i386) Mapbox.framework.dSYM/Contents/Resources/DWARF/Mapbox
UUID: 2DC125FA-D463-3D81-AB23-5FD069BE495B (x86_64) Mapbox.framework.dSYM/Contents/Resources/DWARF/Mapbox
UUID: C2B7A924-9D31-3681-9322-6A7FD5479604 (arm64) Mapbox.framework.dSYM/Contents/Resources/DWARF/Mapbox
…

This is the first build of my app that I’ve submitted with Xcode 9 so I wouldn’t be surprised if that has something to do with it.

[boundsj]

@brblakley how are you installing the Mapbox iOS Maps SDK in your project? Note that, if you do it manually, you will need to add a script (https://www.mapbox.com/install/ios/download/) to strip out the simulator slices that are apparently still there based on your dwarfdump output.

[brblakley]

@boundsj, thanks for the quick response. I used CocoaPods 1.3.1. My Podfile looks like this:

platform :ios, '10.0'
use_frameworks!
inhibit_all_warnings!

target 'MyApp' do
    …
    pod 'Mapbox-iOS-SDK'
    …

    target 'MyAppTests' do
        inherit! :search_paths
    end

end

[jmkiley]

This may be related to https://github.com/CocoaPods/CocoaPods/issues/6819. I tested out CocoaPods v1.2.1, v.1.3.1, and v1.4.0-beta.1 and found that the archived app contains a different combination of dSYM files with each version.

v1.3.1 creates a dSYM of just the Mapbox.framework.dSYM (which includes armv7, x86_64, i386, and armv64 slices), whereas v1.2.1 creates a dSYM of just MyApp.app.dSYM. v1.4.0-beta.1 seems to include both dSYMs. So there are more slices archived with more recent versions of CocoaPods.

[boundsj]

@brblakley @jmkiley I'm sorry, I just glossed over the fact that the report was about a warning email about the dSYMs and not the framework binary.

Here is what I think is happening:

For iOS, this project is published as a pre-compiled binary that CocoaPods and Carthage can download and link or make available to link to the application project. The binary contains slices for device and simulator architectures. We also include the corresponding architecture slices in the dSYM that we package up in the release. This make sense because we want the developer to be able to have all the possible pieces.

However, it does not look like CocoaPods has any means to strip the simulator slices from our provided, pre-created dSYM. As of https://github.com/Carthage/Carthage/pull/1023, Carthage will do the right thing and, when an app project is archived for submission to the iTunes Connect, the Mapbox.framework.dsym that is sent will only contain armv7 and arm64 slices. It does not look like CocoaPods has such a mechanism so the same "fat" dSYM that we ship in the published SDK is passed through to iTunes Connect.

So, as best I can tell, this is an issue that would need to be solved by CocoaPods. Using Carthage appears to be a workaround. You could also consider using CocoaPods and stripping the Mapbox dSYM file before submission to iTunes Connect at some point in the process.

[boundsj]

Looks like this is moving in https://github.com/CocoaPods/CocoaPods/issues/7111#issuecomment-334855012. I'm going to close here for now. Thanks for the report @brblakley!

[siddharthadeb]

I am getting same issue with MAP box binary while uploading to ITUNES connect. Please help me out with your right process or answer.

I did same as you said - You could also consider using CocoaPods and stripping the Mapbox dSYM file before submission to iTunes Connect at some point in the process.

[jmkiley]

Hi @siddharthadeb -

It looks like this issue should be fixed in CocoaPods v1.4.0-beta.2. See this upstream issue for more information. In the meantime, using Carthage or an pre-1.3.0 version of CocoaPods seem to be the other options.