Archive for iTunes Connect fails with ./Mapbox.framework/Mapbox' was built without full bitcode

[roblabs]

Attempting to build Mapbox iOS 3.3.0 for sending app out for TestFlight, then to customers on the App Store.

I am receiving the below error regarding 'not built with full bitcode'. Our last App Store build was 3.2.2 and make ipackage worked without any flags. Now we are seeing the issue, and the flag BITCODE=YES does not solve anything.

Any suggestions or workarounds? We have bitcode on in our app, and we prefer to have bitcode on due to its advantages from Apple.

Issue looks similar to #5448.

Platform: iOS
Mapbox SDK version: 3.3.0
SHA = 5389f04
Xcode Version 7.3.1 (7D1014)

Steps to trigger behavior

1. make clean
2. Make with BITCODE=YES
3. make ipackage BITCODE=YES
4. copy mapbox-gl-native/build/ios/pkg/dynamic to my project
5. From Xcode for my target, Product > Archive

Expected behavior

Happy Archive, ready for iTunes Connect and the App Store

Actual behavior

Archive failed with this error

ld: bitcode bundle could not be generated because '/Users/me/bitbucket/project/Mapbox.framework/Mapbox' was built without full bitcode. 
All frameworks and dylibs for bitcode must be generated from Xcode Archive or Install build for architecture armv7
clang: error: linker command failed with exit code 1 (use -v to see invocation)

[1ec5]

make ipackage produces a fat binary that contains slices for the simulator as well as the device. Simulator slices can’t be built with Bitcode support, because the x86_64 architecture doesn’t support it. (The iTunes Connect error could be clearer about this.) In our installation instructions, one of the steps is to add a Run Script build phase that runs strip-frameworks.sh. That script strips the simulator slices when archiving, since simulator content isn’t allowed in App Store submissions anyways.

If you add that build phase, archive, and resubmit, do you still get the same error?

[roblabs]

Yes, the above was using strip-frameworks.sh.

make ipackage is part of my release to App Store process, so things have been working since releasing with Mapbox 3.2.1 & 3.2.2 builds. That is 3 months of product releases on the App Store with strip-frameworks working as expected.

I've also tried make iframework BITCODE=YES, with no luck.

[1ec5]

Have you always had to pass in BITCODE=YES as part of your build process? platform/ios/scripts/package.sh used to recognize the BITCODE flag as a way to support building without Bitcode. All it did was set the ENABLE_BITCODE compiler flag when invoking xcodebuild. In f791eb3 for #4641, we streamlined package.sh by removing the BITCODE override. ENABLE_BITCODE=YES should be set in the Xcode projects anyways; is this not the case?

[roblabs]

Our build process has only used make ipackage since Mapbox 3.2.1. The BITCODE=YES is my attempt get around the today's Archive issue.

I did search in platform/ios/ios.xcworkspace and found that the KIF project has ENABLE_BITCODE=NO. That is the only reference to bitcode in the workspace. I apologize, I don't know what KIF does.

Could that be the problem?

[1ec5]

That’s unlikely, because KIF is only included in the UI test bundle, not the dynamic or static framework targets.

[boundsj]

This should be fixed by #5586 in the next beta or release candidate.

[roblabs]

I have verified that I can now Archive a full bitcode build. Using sha 687013b.

thanks @boundsj for the quick turnaround.