Invalid Swift Support - Files don't match Xcode 10.1
up vote
2
down vote
favorite
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.
xcode xcodebuild xcode10 xcode-command-line-tools
asked Nov 8 at 19:05
Dheeraj
336
add a comment |
up vote
2
down vote
favorite
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.
xcode xcodebuild xcode10 xcode-command-line-tools
asked Nov 8 at 19:05
Dheeraj
336
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 9 at 23:36
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 9 at 23:40
add a comment |
up vote
2
down vote
favorite
up vote
2
down vote
favorite
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.
xcode xcodebuild xcode10 xcode-command-line-tools
asked Nov 8 at 19:05
Dheeraj
336
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.
xcode xcodebuild xcode10 xcode-command-line-tools
xcode xcodebuild xcode10 xcode-command-line-tools
asked Nov 8 at 19:05
Dheeraj
336
asked Nov 8 at 19:05
Dheeraj
336
edited Nov 14 at 0:23
asked Nov 8 at 19:05
Dheeraj
336
asked Nov 8 at 19:05
Dheeraj
336
asked Nov 8 at 19:05
Dheeraj
336
336
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 9 at 23:36
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 9 at 23:40
add a comment |
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 9 at 23:36
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 9 at 23:40
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 9 at 23:36
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 9 at 23:36
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 9 at 23:40
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 9 at 23:40
add a comment |
1 Answer
1
active
oldest
votes
up vote
2
down vote
accepted
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.
answered Nov 11 at 20:39
Scott K.
1,5691322
Thank you so much! We also have something similar on our Xcode 10.1 machines. And we are using the belowlipocommandsudo 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.dylibDo we need to do it for all the dylibs to get the error removed and generate our ipa's again?
– Dheeraj
Nov 13 at 0: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 at 18:24
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
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.
answered Nov 11 at 20:39
Scott K.
1,5691322
Thank you so much! We also have something similar on our Xcode 10.1 machines. And we are using the belowlipocommandsudo 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.dylibDo we need to do it for all the dylibs to get the error removed and generate our ipa's again?
– Dheeraj
Nov 13 at 0: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 at 18:24
add a comment |
up vote
2
down vote
accepted
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.
answered Nov 11 at 20:39
Scott K.
1,5691322
Thank you so much! We also have something similar on our Xcode 10.1 machines. And we are using the belowlipocommandsudo 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.dylibDo we need to do it for all the dylibs to get the error removed and generate our ipa's again?
– Dheeraj
Nov 13 at 0: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 at 18:24
add a comment |
up vote
2
down vote
accepted
up vote
2
down vote
accepted
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.
answered Nov 11 at 20:39
Scott K.
1,5691322
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.
answered Nov 11 at 20:39
Scott K.
1,5691322
answered Nov 11 at 20:39
Scott K.
1,5691322
answered Nov 11 at 20:39
Scott K.
1,5691322
answered Nov 11 at 20:39
Scott K.
1,5691322
1,5691322
Thank you so much! We also have something similar on our Xcode 10.1 machines. And we are using the belowlipocommandsudo 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.dylibDo we need to do it for all the dylibs to get the error removed and generate our ipa's again?
– Dheeraj
Nov 13 at 0: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 at 18:24
add a comment |
Thank you so much! We also have something similar on our Xcode 10.1 machines. And we are using the belowlipocommandsudo 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.dylibDo we need to do it for all the dylibs to get the error removed and generate our ipa's again?
– Dheeraj
Nov 13 at 0: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 at 18:24
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 at 0:16
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 at 0: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 at 18:24
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 at 18:24
add a comment |
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53214530%2finvalid-swift-support-files-dont-match-xcode-10-1%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
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 9 at 23:36
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 9 at 23:40