Invalid Swift Support / The SwiftSupport folder is empty

Question

Environment: Xcode 7 GM

I uploaded iOS app successfully using Xcode without error. This app is written in Objective-C and Swift.

However, immediately after successful upload, I got this email from Apple stating this error:

Invalid Swift Support - We have discovered one or more issues with your recent delivery for XXXXX(my app name). To process your delivery, the following issues must be corrected:

Invalid Swift Support - The SwiftSupport folder is empty. Rebuild your app using the current public (GM) version of Xcode and resubmit it.

Once these issues have been corrected, you can then redeliver the corrected binary.

Anybody has a solution against this issue?

I have already confirmed below issues.

"SwiftSupport/iphoneos/" libraries in archives(.xcarchive file) is equaly to "Products/Applications/myApp.ipa/Frameworks/"

My "Valid Architectures" setting is "$(ARCHS_STANDARD)" displaying "armv7k".

Provisioning profile is set to Dev and Release which has been created in iTunes connect, respectively.

And, in my "Edit scheme", Test target is unchecked at Archive.

score 61 · Accepted Answer · edited May 23 '17 at 12:26

61

important note: this only works for projects that do not use swift, see comment below

I just met the same issue and resolved it by making the following change - If you used to have Swift files in your project but then removed them, you only need to set "Embedded Content Contains Swift Code" to NO in Build Options.

edited May 23 '17 at 12:26

Community

1
1

answered Sep 20 '15 at 23:51

aaa

1,649
1
16
22

up voted. I met same situation on next submit process, but this works well. – Tsuyoshi Endo Oct 09 '15 at 06:52
15

This is not recommended for projects using swift files right?? I am using the swift files and i am getting the same issue.. – Saikiran Komirishetty Nov 27 '15 at 08:45
this happened to me after I archived an Appcelerator project directly from Xcode and your answer fixed it. – Alberto M Jul 28 '16 at 10:18
What if you use cocoapods that rely on objective c? – user805981 Dec 31 '16 at 03:59
6

Has this been renamed (8.2.1)? I only see "Always Embed Swift Standard Libraries". Mine is set to NO, and doesn't help. – Joel Feb 11 '17 at 17:33
I can't find this option either. – mattsson Sep 19 '17 at 10:24
1

I have same issued but this solution not working for me any other solution for this? – Purushottam Padhya Feb 02 '18 at 05:49

score 16 · Answer 2 · answered May 17 '16 at 02:59

when try to export after "Xcode->Product->Archive" you should choose "save for ios app store deployment" option

The same problem confused me a couple of days, the above setting can solve this problem.

no matter "embedded content contains swift code" is yes or no.

score 15 · Answer 3 · edited May 23 '17 at 12:10

There are many conflicting answers on this page.. what worked for me was the one mentioned here, which is simply select a save for iOS app store deployment option (I'm actually not interested in an app store release.. I want to simply push a release for testflight internal testing)..

that being said, I have a way to verify that your ipa will be approved or not before submitting it:

drag the .ipa file into a new folder (call it analysis)
right click the ipa file and rename it to .zip (confirm the dialog to use .zip)
double click the zip file

here if you get a folder (with the same name as the .ipa file) that has the following subfolders in it:

payload
swiftSupport
Symbols

then you are good to go, however if you only see the Payload folder within.. then you gotta try again

also a couple of pointers

I've tried setting "Embedded Content Contains Swift Code" to NO, it worked just once then stopped working after that
I've ensured that I had no cocoapod errors.. that didn't help either
I've tried manually adding the SwiftSupport folder inside the archive as suggested here.. but then i got all sorts of side effects.. didn't work

conclusion

I think this is due to some bug with xcode (writing this with Xcode 8.0 build (8A218a).. so keep on trying your luck until it works.. just don't expect some solid explanation for it

"then you are good to go, however if you only see the Payload folder within.. then you gotta try again", could you please tell me what do you mean by saying "then you gotta try again"? try again to what? I facing trouble with this issue, please help. — Ahmad F, Nov 17 '16 at 14:29
So there really is no solution for this? I'm using Xcode 8.2.1 now and facing the same issue. Would love to know how you were able to resolve this issue? I'm using both swift and objective c code in cocoapods — user805981, Dec 31 '16 at 04:16
"try what again" again like i said there is no solid fix to this solution.. my post isn't about a solution as much as it is about a way to verify if your attempt was successful or not _before_ you submit to app store — abbood, Jan 15 '17 at 07:50
Using XCode 8.2.1 as well, but this solution is if you are using Swift, or not? I don't care to bloat the deliverable since I'm _not_ using Swift... Also how did you add that folder? — Joel, Feb 11 '17 at 17:30

score 9 · Answer 4 · answered Dec 08 '15 at 10:32

Five Step Solution:

Go to build settings and make flag Embedded Content Contains Swift Code -> YES, if your code contains partial swift code or entirely made in Swift
Archive your build using Xcode->Product->Archive
Export the Archive Build you will suddenly see the difference build size will be 40+ MBs this is because XCode has added SwiftSupport folder which was missing
Now upload this build using Application loader
If this does not work check that if you have multiple XCode on your system goto Xcode->Preferences->Location->Command Lines Tools has the same latest or the same Xcode from drop down selected on which you have done the coding & vola it's done.

This is slightly a drawback as swift carries the baggage and has to be compatible with earlier version and Objective C code.

My many hours were wasted hope you will find this helpful ;)

Exporting as app store and upload from Application loader works for me Thanks. — Hardik Mamtora, May 26 '16 at 05:40

score 7 · Answer 5 · answered Apr 11 '16 at 11:08

7

This error can happen if you use xcodebuild to export the IPA without specifying the -exportOptionsPlist option

See xcodebuild -help for the available keys, but you probably want a plist with at least the method key set to "app-store", like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>method</key>
    <string>app-store</string>
</dict>
</plist>

answered Apr 11 '16 at 11:08

Jon N

1,439
1
18
29

does this only work for when submitting a build to the app store? what if i want to submit a build for internal test flight testing? – abbood Sep 17 '16 at 06:37
But getting this error in mail after processing in iTunes connect - Invalid File Permissions - You must have read and write permissions to the file at /SwiftSupport/iphoneos/libswiftCore.dylib. and all other swift dylibs. – itscoderslife Dec 16 '16 at 10:49
If I'm just using Product->Archive how does this get applied? – Joel Feb 11 '17 at 17:32
@Joel these keys basically match the Xcode UI fields on the archive screen, which are applied automatically by Xcode. – Jon N Feb 12 '17 at 11:35
where do i put the method key ..in which plist file please tell me. – vaibhav May 05 '17 at 18:02
@vaibhav use the -exportOptionsPlist of xcodebuild to specify which plist file. Have a read of xcodebuld -help. – Jon N May 05 '17 at 22:27
Does anybody know how I might specify the -exportOptionsPlist option while using fastlane? – BigSauce Jun 07 '17 at 17:31

score 6 · Answer 6 · answered Nov 11 '19 at 17:33

6

I spent almost an entire day on this issue, none of the above solutions worked. I got rid of this error by lowering my target tvOS back to 11 from 13; where it was originally. That restored the SwiftSupport folder. The question that remains to be answered is whether this is due to our Provision not allowing us to target tvOS 13 - or somehow the Apple Store folks not being aligned with the xCode folks because the app created by targeting tvOS 13 is 14mb and tvOS 11 is 44mb and different app folder structure.

answered Nov 11 '19 at 17:33

T_coder

141
2
5

I tried pretty much all the other suggestions before trying this. Moving back to target support for iOS 12+ worked for me too. – Vik Dec 12 '19 at 16:17
This was the only thing that solved my problem. I moved the iOS target back to 11.4, and it worked. (It was a Swift only project) – Tiny Instance Feb 05 '20 at 17:08
Your answer was hint for my case. I had to raise my target to 13.0 from 11.0 because my app was using SceneDelegate. – NightFury Jul 01 '20 at 23:06

score 5 · Answer 7 · answered Jun 25 '20 at 05:35

I received this same email after uploading an .ipa file to App Store Connect through the Transporter app. The following is where I went wrong: I distributed the app using ad hoc.

The following steps are the solution for my error:

Archive app
Distribute on TestFlight and the App Store
Export
Open ExportOptions.plist in the newly created folder from the export.
Make sure the method property has the value app-store if you are uploading to App Store Connect/TestFlight like me.
Drag and drop the exported .ipa file to Transporter.
Deliver your app to upload it.

And that's it!

score 3 · Answer 8 · edited May 24 '16 at 09:02

3

I grappled with this for several hours and here is what worked for me.

In the Archive, Xcode did not copy swift libs into SwiftSupport/iphoneos even though my project had "Embedded Content Contains Swift Code" set to yes for all targets. Nor did it copy swift libs into "AppName.app/Frameworks". So I had to do that manually in the Archive before submitting:

copy "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphoneos/lib*" to "Archive_folder/Products/Applications/AppName.app/Frameworks" and "SwiftSupport/iphoneos"

If your app also has a watch app

copy

"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/watchos" into "Archive_folder/SwiftSupport/watchos" and "Archive_folder/Products/Applications/AppName.app/Watch/AppName WatchKit App.app/Frameworks"

Then submit the app.

edited May 24 '16 at 09:02

C0mrade

1,215
1
10
23

answered Jan 03 '16 at 17:14

Ken Roy

915
1
10
15

1

this answer will need to be a lot more detailed.. for example how exactly do you do his copy/paste/archive? for example i did this myself and i got errors like `.DS_store found in path` and `couldn't find `embedded.mobileprovision` file although it was clearly there.. the devil is in the details my friend – abbood Sep 17 '16 at 07:35
This worked for me with this additional caveat: There is one `.dylib` that should not be copied and that is `libswiftRemoteMirror.dylib`. Otherwise your app will be rejected with the following message: *The file libswiftRemoteMirror.dylib doesn’t have a signing ID.* – Franch Mar 25 '19 at 20:02

score 3 · Answer 9 · answered Jul 18 '17 at 11:37

App Store build submission Issue:

Invalid Swift Support - The SwiftSupport folder is missing. Rebuild your app using the current public (GM) version of Xcode and resubmit it.

Solution:

In most cases we found this issue due to submitting application via App Loader and our usual practice to make ipa as Organizer > App Archive > Show In Finder > Show Package Content > Products > Applications> OurProjectName.app in copying this app to Payload folder and zip it and making ipa file to submit on App Store using App Loader. That is work fine for submitting only objective c files contained projects.

But there is some changes if your project contains any swift classes and usage of it. If your project contains swift classes with Objective C project, IPA content structure changed slightly different as attached screenshot.

To fix this issue, submit app directly from Xcode [ OR ] if you want to submit application via App Loader than first Export ipa using Export option from Xcode organizer and submit those ipa file to app store via App Loader.

See the reference screenshot as below:

Hurrey!!! Your issue will be fixed :) :) :)

score 2 · Answer 10 · answered Jan 04 '18 at 14:07

2

My problem was that I was using an adhoc profile to submit to TestFlight (has to be a distribution provisioning profile). Great error messages Apple!

answered Jan 04 '18 at 14:07

Radek Czemerys

1,060
7
17

score 2 · Answer 11 · answered Jul 26 '20 at 17:28

2

This happened to me after I changed project settings. Go to "File" > "Project Settings..." (or in some cases "Workspace Settings...") and then select "Use Shared Setting" from the "Build System" dropdown.

answered Jul 26 '20 at 17:28

Pashynia

47
2

score 2 · Answer 12 · answered Aug 27 '20 at 05:29

2

Tried this solution with Xcode 11.6, in Aug 2020, and it works.

Select the archive > Show in Finder
Show Package Contents
Delete the folder SwiftSupport
Go back to the archive > Distribute App

answered Aug 27 '20 at 05:29

samwize

25,675
15
141
186

score 1 · Answer 13 · answered Dec 01 '15 at 12:25

Setting "Embedded Content Contains Swift Code" to $(inherited) worked for me. The warning after executing the CocoaPods command pod install helped me to find this out.

[!] The `applewatch Extension [Debug]` target overrides the `EMBEDDED_CONTENT_CONTAINS_SWIFT` build setting defined in `Pods/Target Support Files/Pods-applewatch Extension/Pods-applewatch Extension.debug.xcconfig'. This can lead to problems with the CocoaPods installation
- Use the `$(inherited)` flag, or  <--------------
- Remove the build settings from the target.

Well, this method seems to have stopped working for me and I know get the "exceeds 50mb size limit" error. — Ken Roy, Aug 10 '16 at 19:22

score 1 · Answer 14 · answered May 01 '17 at 23:36

1

Using Save for iOS App Store Deployment instead of Save for Ad Hoc Deployment Xcode export option solved this issue for me. Counterintuitively, you should use the first option even for TestFlight builds.

answered May 01 '17 at 23:36

Alexander Vasenin

11,437
4
42
70

can I use "Save for Enterprise Deployment" option for TestFlight builds? – Suresh Durishetti Feb 27 '18 at 12:33
@SureshDurishetti I haven't tried it, but most likely it won't work. It supposed to work only for special _enterprise_ development program. – Alexander Vasenin Feb 27 '18 at 17:26

score 1 · Answer 15 · answered Jul 11 '17 at 14:10

1

You also get this error when you upload an ipa that has a plist with export_method set to ad-hoc instead of app-store to itunes ...

answered Jul 11 '17 at 14:10

TheEye

9,280
2
42
58

score 0 · Answer 16 · answered Aug 10 '16 at 19:35

Here's what I am doing now to solve this issue since my method above stopped working. Keep in mind that my code's main app is Obj-C and my watch app is Swift.

Make sure the "embedded Content Contains Swift Code" is set to:
- YES for app target
- NO for WatchKit Extension
- YES for Watchkit App
After Archiving my XCode will not create the "[archive folder]/SwiftSupport/iphoneos", but will create and fill the "[archive folder]/Products/Applications/[app name].app/Watch/\ WatchKit\ App.app/Frameworks" with the Swift dylibs. So I created the following soft link:

ln -s "[archive folder]/Products/Applications/.app/Watch/\ WatchKit\ App.app/Frameworks" "[archive folder]/SwiftSupport/iphoneos"

Then when I submit via XCode Organize it is accepted without error.

If you simply copy the files rather than linking them then you risk the watch app exceeding the 50MB limit.

BigSauce · Answer 17 · 2017-06-15T16:27:36.257

Setting Always Embed Swift Standard Libraries to Yes is only necessary for Objective-C targets which link against your own frameworks which depend upon Swift. In cases where you are not linking against (i.e., using) an internal framework which depends upon Swift, Xcode will embed the Swift standard libraries in your archive as long as there is at least one occurrence of importing a Swift standard library in a Swift file which is part of the build target.

In other words, if your target has a Swift file which doesn't import any Swift standard libraries––via "import Foundation", for example––then Xcode will not copy the Swift Standard libraries into the archive.

The fix for this issue is to ensure that at least one of the Swift files in your target is importing a swift standard library (e.g., "import Foundation").

Daniel Jalkut has a very informative post about Swift dependencies which sheds light into this issue.

score 0 · Answer 18 · answered May 04 '20 at 05:34

0

I grappled with this issue for a while and nothing above worked. In a last desperate attempt I just deleted the SwiftSupport folder from my archive.

To my surprise it uploaded and completed processing successfully. Hope this help someone.

answered May 04 '20 at 05:34

Tomch

51
1
2

score 0 · Answer 19 · answered May 19 '20 at 14:55

0

I managed to fix this error by unchecking the option "Strip Swift symbols".

App Store Connect distribution options

answered May 19 '20 at 14:55

Emerson Nascimento

1

score 0 · Answer 20 · answered Jul 10 '21 at 05:48

To delete the SwiftSupport folder from the .ipa I used the following script

ipa_path="${DIR_ON_CI}/ipa_name.ipa"
zip -d "${ipa_path}" "SwiftSupport*"

You'll need to set proper ipa_path. Nothing else seems to work in my case and the app was built on a CI where I have access to the .ipa after the archive is exported.

Invalid Swift Support / The SwiftSupport folder is empty

20 Answers20

conclusion

Linked