A while back I was trying to submit an App using Xcode version 11.1 (11A1027) but I received an email from Apple with the following message:
ITMS-90424: Invalid Swift Support - The SwiftSupport folder is empty. Rebuild your app using the current public (GM) version of Xcode and resubmit it.
From what I know, 11A1027 is already a released version and so I am not very sure why there is a need to use the GM version of Xcode. Does anyone have any idea?
I tried some of the methods suggested in other posts but somehow could not resolve it.
Is this a bug in Xcode?
Solved for me in June 2020.
MacOS Catalina 10.15.5
Xcode Version 11.5 (11E608c)
Check that Command line tools(Xcode->Preferences->Locations) have this value
Configure PROJECT in project settings
Click to you project in Xcode.
Select project name
Set filter to Basic and Levels
Find Always Embed Swift Standard Libraries field (if not found - play with filters)
Set YES to this field for PROJECT(debug and release)
Configure TAGET in target settings
Click to you project in Xcode.
Select target name
Set filter to Basic and Levels
Find Always Embed Swift Standard Libraries field (if not found - play with filters)
Set YES to this field for PROJECT(debug and release) and set NO to this field for TARGET(debug and release)
see example
Clean project and create archive(Product->Archive)
In the dialog window right click to the created archive name -> Show in Finder
Right click to the archive name in Finder -> Show Package Contents
Delete SwiftSupport folder here
After that upload your build using AppStore Connect in Xcode with default settings.
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!
Original answer here: https://stackoverflow.com/a/62568526/10374366
I don’t think it’s a bug. But the best thing you can do is to just reinstall Xcode from the AppStore.
The solution here was in this "Invalid Swift Support - The SwiftSupport folder is missing" with Xcode 7.3.1. We needed to use the new -exportOptionsPlist flag with xcodebuild instead of the older -exportFormat and -exportWithOriginalSigningIdentity flags. The plist just needs to have the method key set to app-store.
Try upgrading to swift 5.0 and going to workspace settings, build system and set it to New Build System. This solved it for me in a React Native project using native iOS views. As far as I know swift 5 makes doesn't use the swift support folder any more.
I have updated a currently submitted Titanium app and added a watch extension using swift.
Everything works fine if I build and test on sim and build directly to device. I only get an issue when I submit the app to the Apple app store (via XCode Organizer).
The binary submits, passing validation but I get am email from iTunes Connect as follows:
Dear developer,
We have discovered one or more issues with your recent delivery for "xxxxxxxxxxx". To process your delivery, the following issues must be corrected:
Invalid Swift Support - The SwiftSupport folder is missing. 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.
It seems as though it may be related to a build setting: Embedded Content Contains Swift Code.
It looks like this needs to be set to Yes if the Titanium project contains embedded Swift.
As of now I am stuck as I cannot submit the app. Is this a Ti problem or is there another step I should follow?
XCode: 7.3, SDK: 5.2.2.GA - Project created and built using only the Ti CLI.
First you should check your .ipa file by
unzip yourapp.ipa
If the only Payload exists, the Apple reject your app.
You should create SwiftSupport/iphoneos directory and put the appropriate
swift library files.
You can know which libraries are necessary by checking Payload/yourapp.app/Framesworks. But this library files can not be used as SwiftSupport/iphoneos.
You must copy the appropriate libraries from your mac's /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphoneos directory. The file names are same as the above Payload/yourapp.app/Frameworks but the contents are different.
After you get the Payload and SwiftSupport directory, do package these directories by
$ zip -r yournewapp.ipa Payload SwiftSupport
(Remark: remove all .DS_Store files if exist)
Then Apple accespt yournewapp.ipa.
For future reference: I had to Archive the Titanium project through Xcode because one of my third-party libraries requested to execute a script in the Build phases.
Received the same message from Apple and fortunately fixed it just changing the Embedded Content Contains Swift Code to No.
You should choose "Save for iOS App Store Deployment" option at the time of exporting ipa file.
This issue has now be resolved, there is a new version of the Titanium SDK, 6.0.1.GA that specifically has a fix in for this issue. I have now created, submitted and have a Titanium app with associated watch app now published in the app store.
I get this error after adding a Swift class to an old Xcode project.
dyld: Library not loaded: #rpath/libswift_stdlib_core.dylib
How can I make the project run again?
For me none of the previous solutions worked. We discovered that there is a flag ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES (in earlier versions: "Embedded Content Contains Swift Code") in the Build Settings that needs to be set to YES. It was NO by default!
This error can occur if something went wrong during the conversion of an Objective-C project to start using Swift. The issue is that the Linker build settings never got configured properly, so you'll have to do it by hand. Look for the Runpath Search Paths build setting and set it to:
$(inherited) #executable_path/Frameworks
EDIT: I should also add that there has been recent spate of these errors caused by something else entirely - Apple made a change in Swift itself, starting in perhaps Xcode 6.1 or 6.1.1. The only solution seems to be to quit Xcode, destroy your certificates in Keychain Access, go to the Member Center and delete all certificates and profiles (except the profiles for apps in the Store - you can't delete them), and then start the entire certificate request process from scratch.
I'm not really sure why this question is being downvoted, I had this problem as well when I first tried to use Swift with an existing project. An Xcode restart also fixed this for me.
I searched long on this issue. There are several reasons causes this issue.
If you are facing when you and Swift code/library in an Objectice C project you should try Solution 1-2-3
If you are facing this issue with a new a Swift project Solution 4 will fit you best.
Solution 1:
Restart Xcode, then computer and iPhone
Solution 2:
Go to project build settings and set Always Embed Swift Standard Libraries (previously Embedded Content Contains Swift Code) flag to YES
Solution 3:
Go to project build settings and add #executable_path/Frameworks to Runpath Search Paths option
Solution 4:
If none of above works, this should. Apple seems to be ninja patched certificates as mentioned in AirSign's post
At InHouse certificates
Subject: UID=269J2W3P2L, CN=iPhone Distribution: Company Name, O=Company Name, C=FR
they added a new field named OU
Subject: UID=269J2W3P2L, CN=iPhone Distribution: Company Name, OU=269J2W3P2L, O=Company Name, C=FR
so you should just recreate certificate and provision
In my case I was trying to import a custom framework and was getting the similar error.
Turns out I had to import the framework in the Embedded Binaries rather than in to the Linked Frameworks and Libraries.
Embedded Binaries are under Projects Settings -> -> General
For developers who have had this issue with a Adhoc/Enterprise distribution builds,
Create the production certificate from dev portal and then regenerate the distribution profile. Download and install both of them on your Mac. Ensure you selected the right profile in your Xcode build settings and rebuild your app.
Source: https://devforums.apple.com/message/1022908#1022908
Solution 5:
In my case, all solutions mentioned in the answer of accfews were very helpful but none has worked. I solved my problem by adding my swift library in the section "Embedded Binaries" in the "General" section of my Project's target. Perhaps is this due to the fact that I have included my swift framework in my workspace? Whatever it compiles now! Get ready Swift, I'm here!
A simple restart of Xcode solved the issue for me.
For me, the issue was due to the fact that my Apple Worldwide Developer Relations Certification Authority was invalid.
Download it from here:
https://developer.apple.com/certificationauthority/AppleWWDRCA.cer
Drag and drop it into Keychain Access, clean the project, and run.
I had an Obj-C project where I started adding swift source files.
The following fixed the issue for me:
Linking: RUNPATH SEARCH PATHS = $(inherited) #executable_path/Frameworks
Swift Compiler - Code Generation: EMBEDDED CONTENT CONTAINS SWIFT = YES
I just created a new project from the templates Xcode 6.3 and compared the project settings with my old original project.
Try to hold Alt, then go to Product -> Clean Build Folder...
Hope it will help someone..
The reasons for this occurring are many. Having just spent a fun weekend finding yet another issue that causes this (the order of code signing), I wanted to create a summary answer that brings all the possible solutions together:
Add Embedded Content Contains Swift Code to project. You need to set this flag if your app contains Swift code.
Clean project. In addition to a Project > Clean you can also delete the DerivedData and Build directories. Look under the Preferences for the location of DerivedData. Build should be in your project folder.
Ensure Runpath Search Paths contains #executable_path/Frameworks.
Ensure that your certificate contains your Apple Team ID in the OU (Organization Unit) field Apple will add this for you, just revoke your existing distribution certificate and create a new one, download, install on KeyChain, regenerate all provisioning profiles, download those and rebuild.
Xcode restart. If everything is basically good, but Xcode hasn't gotten there yet.
That's the easy stuff. If you are doing your own command line build you may be creating your own .ipa files to upload. In that case you need to ensure the following:
Make sure the version of the Swift files in SwiftSupport/iphoneos is the same as the version in Contents/YourApp.app/Frameworks Because Swift is not yet binary compatible between version, you must ensure these versions are the one that you built your app with. You can find these libraries under /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphoneos.
Sign the libraries and frameworks first. You need to codesign the libraries and framework files (under Frameworks in the .app folder) first and then sign the entire .app tree. The .app tree must be signed with an entitlements.plist but not the frameworks.
Hopefully when Swift 3.0 comes out and we no longer need to bundle Swift with our apps this whole issue will go away.
I had this issue using an Ad Hoc (or enterprise) mobileprovision with a production certificate. Switching to a development certificate and mobileprovision solved the issue.
My project is a Swift project with some Objective-C classes.
I had the same problem when signed with old inHouse (enterprise) certificate.
The following steps fixed this for me.
Create and use a new certificate and mobile provision.
(Ref. AIRSIGN’s blog)
Set Runpath Search Paths build setting to: $(inherited) #executable_path/Frameworks.
(Ref. matt’s answer)
Solution 6:
In our case, the Enterprise Distribution Certificate had been revoked. Generating a new certificate and updating the provisioning profile fixed the issue.
(There seems to be many different causes for this error. Hope this helps someone.)
I tried all the answers given above, nothing worked.
Finally worked after updating to Yosemite
I have faced the same issue, setting the right code sign identity solved the problem(Build settings->Code Signing Identity).
As per Apple technical question "All Enterprise and standard iOS developer certificates that are created after iOS 8 was released have the new Team ID field in the proper place to allow Swift language apps to run"
If you add the three frameworks via Embedded Binaries, they will be added to Linked Frameworks and Libraries also. Delete the three entries in Linked Frameworks and Libraries will solve the problem.
Magic methods such as relaunch Xcode and restart the Mac doesn't work on me.
Adding Framework as "Embedded Binary" instead of just "Linked Frameworks and Libraries" - Fixed my issue.
I also set Embedded Content Contains Swift Code flag to YES.
Upgrade to Latest Version of OS X (Yosemite)
After hours of trial & error I came to the resolution of this problem.
- If this applies to your case of course.
I had the same problem until I upgraded my Mac OS X from Mavericks to Yosemite.
- It fixed my problem, hope it fixes yours as well
I tried all the solutions that found on web, including to Apple and new certificates. Without success.
The only way I could run xcode, after 6 months of trying, was creating a new account on my macbook.
Usually this error will disappear if you add this library to the "Copy Files" segment in your Build Phases.
My environment: Cocos2d 2.0, Box2d, Objective C
In addition to doing the other answers above I finally went to the General tab and made WatchKit Optional.
And if all of the above doesn't help you and you really get frustrated... Try the best trick of all: Clean and just to be sure also Clean Build Folder. :) Hope it helps somebody!
None of these solutions seemed to be consistently working for me; after every couple of successful runs, it would fail again. The "Embedded Content Contains Swift Code" flag was always set to YES for me.
Turns out I'd set Xcode to be 6.3-compatible. Changing it back to be 3.2-compatible solved it:
I've had this problem as well, only it wasn't locating libswiftXCTest.dylib.
The solution was to add XCTest.framework to the Tests target, in Build Phases/Link Binary with Library. I was getting this error even when I was trying to build the main target.
This showed up when I added a new Today extension target with Swift language to an old project.
Fixed easily by updating the project to recommended settings. Xcode 6.0.1
I got the same issue using Mavericks, Xcode 6.1.1, testing on an iPhone5 with iOS 8.1.1. I tried all possible solution including new certificates and provisioning profiles, but nothing helped. I did the changes to Embedded Content Contains Swift Code and Runpath Search Paths both on Project level and Target level.
I have now installed Yosemite, and without any further changes, it started to work.
Same issue here, for me it was Crashlytics/Fabric/Beta/Twitter/Whatever-they-call-themselves uploading a binary that was missing the embedded frameworks. If I made an archive and then exported an Enterprise build in the standard way, they worked a charm.
After months and months trying everything here... Definition of insanity... starting Xcode under a new Mac user solved it for me.
I removed ~/Library/Developer/* and reinstalled Xcode- so no clue what else to format to make it work.
We're using a 3rd party library in our iPhone app and when we build it for Release & Device, we're able to find the application in the expected folder (Release-iphoneos), but we also find the library in that same folder.
When uploading the application, do we have to do anything extra with the external library, or is it by default included in the iPhone application?
We do have it included in the Targets -> Application -> Link Binary With Libraries, but we're not sure if that's enough.
The general test is, if you've linked the library and included it in your project, and your app runs on a Device in any mode (Debug or Distribution), then all will be well for the release build.
Check the .app itself! It's just a .zip file that you can open. Change the file ending to .zip and unpack it. You can see if the library is included or not.
[edit:] sorry, i mixed .ipa (which is a combined format for ad-hoc distribution and app-store upload) and the .app
But you can still check that. Use build and archive and export for ad-hoc distribution. (save to file) that will give you an .ipa - if the library is not included in the .app itself, it should be in the .ipa (but I doubt that...)
I'm writing an iPhone app which seems to run fine on the simulator, however when I try and run it on the device I get a libsqlite3.dylib, file is not of the required architecture error. I'm using os 3.0 on a 3GS. Any ideas on what could be causing this?
Thanks!
When you added the SQLite library to your project, it sounds like you chose the one from the iPhoneSimulator sdk. You need to choose the one in the iPhoneOS sdk for whichever version you're building for.
If you still get the error make sure you haven't accidentally copied the simulator version of the lib into your own project directory. You need to delete it if you have. This would have occurred because you accidentally selected 'Copy items into destination groups folder' when you added the lib to your project. Also make sure reference type is 'Relative to Current SDK'.
I had a similar issue which caused by the search paths for the linked library pointing to incompatible files.
I wrote a blog post on how to fix it here:
Fixing the "missing required architecture arm in file" error when developing for iPad