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.
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.
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.
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
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 ;)
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>
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.
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!
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.
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 :) :) :)
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!
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.
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
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.
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.
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 ...
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.
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.
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.
I managed to fix this error by unchecking the option "Strip Swift symbols".
App Store Connect distribution options
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.
I have an app which I want to distribute to the app store.
When I do >Product > Archive does the app automatically build in Release or Debug config? Do I have to set this manually or is it always Release?
You can define Release or Debug in the scheme by tapping on Edit Scheme and selecting the Build Configuration. Take a look at below screenshot:
EDIT: To get Production APNS token
Archive the build in release mode.
Ensure to sign it with an Ad Hoc Distribution Provisioning profile.
Ensure profile is correct by following below:
Verify that the entitlements in the provisioning-profile file are
correct. To do this, open the .mobileprovision file in a text editor.
The contents of the file are structured in XML. In the Entitlements
dictionary locate the aps-environment key. For a development
provisioning profile, the string value of this key should be
development; for a distribution provisioning profile, the string value
should be production.
You can define Release or Debug in the scheme by tapping on Edit Scheme and selecting the Build Configuration
Its better to cross check when you are uploading build to store.
I've a problem by installing an ad-hoc build to my iOS test devices.
When I run the app via XCode, there is no problem, but from the moment I create a signed ad-hoc app (*.ipa), the app is not able to install via iTunes or the iPhone configuration tool.
What I've done:
- Creating a distribution certificate
- Creating an app ID (com.project_name.*)
- Creating a distribution provisioning profile including the distribution certificate, all devices UUID, etc.
- In the plist file I set "Bundle identifer" to "com.project_name.app_name"
By creating the ad-hoc file, I've chose the distribution certificate for code signing. This certificate is also set in the project file --> build settings --> Code-Signing
When I install the app in itunes, there comes an error dialog which just says, that it was not possible to install the app.
Make sure you are not using special characters in bundle identifier.
The bundle identifier string identifies your application to the
system. This string must be a uniform type identifier (UTI) that
contains only alphanumeric (A-Z,a-z,0-9), hyphen (-), and period (.)
characters. The string should also be in reverse-DNS format. For
example, if your company’s domain is Ajax.com and you create an
application named Hello, you could assign the string com.Ajax.Hello as
your application’s bundle identifier. The bundle identifier is used in
validating the application signature.
If your bundle identifier is correct,
Please validate your ipa file with following steps:
Step1: rename yourapp.ipa to yourapp.zip
step2: Extract content of yourapp.zip, you will see content in Payload
folder.
Step3: locate yourapp.app in payload folder.
Step4: rightclick on app and click "show package content"
Step5: in package content, locate "embedded.mobileprovision"
step6: Open "embedded.mobileprovision" in text editor. and check if
your device id exist there.
If your device id is there, Your build is correct. otherwise, rebuild by checking all code.
Note: Please make sure you have selected "Ad-hoc" while creating distribution file and not "App store".
The problem wasn't the app.
My solution: Export the app as Xcode-Project (same way Organizer --> Archive --> Distribute) to another mac. Think about the certificates. You will have to export the private keys from your first mac too (*.p12 files).
Open the XCode-Project from your second mac, sign it with the provision profile and install it via itunes.
I'm goin mad.
I'm using XCode 4 and finally i finished my app,and i was about to submit it to App Store,uploading to iTunes Connect. I tried to to Build for Archive but this warning showed up:
Application failed codesign verification. The signature was invalid, or it was not signed with an Apple submission certificate. (-19011)
I've googled all day long,i've tried to renew all my certificates in Provisioning Center,i've even tried to upload it with Application loader but anything happened. Same error there too. I've tried to validate it through the Archive tab in Organizer but anything, this warning won't go away.
I've read some answers here, and even if the answers were a bit old, anything worked for me, i've tried to reinstall XCode too,i've tried to select the right profile on Build in Targets..
Thanks to anyone who will help me
edit:
When i try to start a new project and select "Build for Archive" and then Archive, the warning appears but i can still share the archive as ipa. I tried to copy all the files from my old project into the new one, build for archive, archived. But when i select "Share" as .ipa it shows an error
The operation couldn't be completed. No such files or directory.
May this be 'cause i added 2 frameworks to my project to work? Should i select something from Target,or Project? Also,i want to say that all my profiles are ok, certificates etc. I've tried to bypass the error -19011 by turning on NO "Validate built product".
EDIT2:
The -19011 doesn't show up anymore, but when i try to validate or submit,i got this error:
The archive is invalid. var/folders/*randomnumbers* app.ipa does not exist.
What am i supposed to do in this case? I've already read some of the answers but none worked.
I solved, thanks to the help of an Apple Technic Engineer, this way:
In targets, on Build Settings - Product name, I had the name of the app with spaces and special characters (? character). After changing that and changing the Bundle Name too, I solved all the problems I got with that.
Hope this will help someone, one day.
You said you tried to "renew all my certificates in Provision Center". Are you certain you are:
Using a valid certificate. Have you imported the private key into your keychain?
Chosen the right provisioning profile + certificate combination for your "Release" or "Distribution" configuration?
It's possible that your Development configuration is correct, hence you could test on your device (if you have), but your Release configuration is wrong.
Go to "Build Settings" in XCode and verify that under "Release" or "Distribution", you chose your Distribution certificate (not development certificate) and the provisioning profile tied to it.
If that doesn't work, your problem is possibly related to
this SO question.
Try reinstalling?
Hope this helps.
Are you sure your distribution certificate is for the app store, and not for ad-hoc distribution?
From Product menu go to "Edit Schema", there find the Archive from the left sidebar and check which build configuration you are using for Archive. It should be distribution.
Another thing to check is which provision profile Distribution configuration is using, you can check this from projects Build Settings under Code Signing section.
After making sure my certificate and provisioning profile were correct for In-House deployment and making sure I didn't have any unwanted spaces or characters in the target names, what worked for me was to change my scheme from Debug to Release on the Run page. Product -> Scheme -> Edit Scheme -> Click Run -> Change Build Configuration to Release.
I've created an app that is reskinnable by just changing asset files. In theory, I could just unzip the IPA file, update my assets, then rezip it as a new version. Of course this doesn't work because of code signing and CodeResources hashes will not match my new assets. Is there anyway I can update CodeResources hashes without having to recompile my app?
Yes. Use the codesign utility. codesign will let you replace any existing signature with one for the identity you specify. (Here's a good blog post on the subject.)
You can see exactly what parameters Xcode is passing to codesign by looking in your build logs. Find the line beginning with "CodeSign AppName...", select it, and then click on the little button that appears to the right. It'll show you the raw codesign command Xcode executed to sign your app. You should be able to unzip the .ipa, replace your assets, zip, and run the command from Xcode to re-sign the app.