10

I know there are similar questions are out there! But, they are old. We have released to iTunes before, never faced an issue. We have bunch of sub projects and also cocoapods. Not sure what could be the issue.

enter image description here

Community
  • 1
  • 1
Dheeraj
  • 233
  • 2
  • 10
  • 1
    According to the Xcode 10.1 release notes, "The App Store and TestFlight don't accept submissions containing arm64e. Xcode will remove arm64e content from your app when you distribute from the Organizer window. (42296212)" – Scott K. Nov 09 '18 at 23:36
  • 1
    So, if you doing a command-line build, it won't go through that path. We are trying removing arm64e from the VALID_ARCHS list, and will update here if that works. – Scott K. Nov 09 '18 at 23:40
  • @ScottK. - Did removing arm64e from the VALID_ARCHS list work for you?. I am having the same issue. – Sagar Natekar Feb 14 '19 at 04:30
  • See my answer below. It's not sufficient to do that since the issue ended up being how we included the standard Swift libraries. – Scott K. Apr 01 '19 at 17:25

1 Answers1

7

Xcode 10.1 has this line in the release notes:

The App Store and TestFlight don't accept submissions containing arm64e. Xcode will remove arm64e content from your app when you distribute from the Organizer window.

In our case, this was the key to fixing it. Our CI uses xcodebuild to compile and archive the IPA, and then uses fastlane to upload it. The first step is to unzip the IPA archive.

Doing that gives us the Swift standard libraries in a SwiftSupport folder and in the application's frameworks folder. Using that release note as a hint, we found that the standard libraries in Xcode 10.1 are shipped with 4 architectures:

% file /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphoneos/libswiftCore.dylib 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphoneos/libswiftCore.dylib: Mach-O universal binary with 4 architectures: [arm_v7:Mach-O dynamically linked shared library arm_v7] [arm64]
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphoneos/libswiftCore.dylib (for architecture armv7):  Mach-O dynamically linked shared library arm_v7
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphoneos/libswiftCore.dylib (for architecture armv7s): Mach-O dynamically linked shared library arm_v7s
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphoneos/libswiftCore.dylib (for architecture arm64):  Mach-O 64-bit dynamically linked shared library arm64
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphoneos/libswiftCore.dylib (for architecture cputype (16777228) cpusubtype (2)):  Mach-O 64-bit dynamically linked shared library arm64

Note the last one, which is in an unknown architecture. That's arm64e. If you upload with these files as is, TestFlight/iTunesConnect will reject your binary with the message you are getting.

For us, the solution was to copy over the standard libraries, use lipo to remove the arm64e slice, then sign them with our distribution certificate. Then we can repackage the IPA archive and upload it.

Hope that helps. It's not clear how you are building your application for submission, so this might be tougher for you to deal with, but for us it wasn't hard to modify our build scripts once we realized what was going on.

Scott K.
  • 1,761
  • 15
  • 26
  • 2
    Thank you so much! We also have something similar on our Xcode 10.1 machines. And we are using the below `lipo` command `sudo lipo /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphoneos/libswiftCore.dylib -remove arm64e -output /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphoneos/libswiftCore.dylib` Do we need to do it for all the dylibs to get the error removed and generate our ipa's again? – Dheeraj Nov 13 '18 at 00:16
  • You're updating them in place, which feels a bit dangerous to me, but that should work. You need to do this for all of the swift libraries, not just libswiftCore.dylib. Once you do that you'll need to regenerate the ipa's so they pick up your modified libraries. – Scott K. Nov 13 '18 at 18:24
  • Can you provide some more details? Where to copy the standard libraires? How to use lipo command to remove arm64e slice? – Awais Fayyaz Apr 17 '19 at 12:01
  • Thanks Scott. I am using Xcode organizer to upload my build. having the same issue. what should i do ? – Awais Fayyaz Apr 17 '19 at 12:02
  • You sir are a life saver! Could Apple's error messages be any less helpful? Btw, I found that Apple would only accept uploads if the Swift libs in `Payload/Frameworks` were signed with the distribution certificate, while those in `SwiftSupport/iphoneos` are *not* signed (i.e. copied directly from the Xcode bundle), making the whole "files don't match" error even more confusing. – devios1 Feb 06 '20 at 18:18