[TIMOB-23313] iOS app rejected because "Invalid Swift Support - The SwiftSupport folder is missing"
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | Critical |
Status | Closed |
Resolution | Fixed |
Resolution Date | 2017-04-08T13:56:42.000+0000 |
Affected Version/s | Release 5.2.2 |
Fix Version/s | Release 6.0.0, Release 6.0.1, Release 6.0.4 |
Components | iOS, Tooling |
Labels | n/a |
Reporter | Fokke Zandbergen |
Assignee | Chris Barber |
Created | 2016-05-04T11:42:41.000+0000 |
Updated | 2018-12-08T18:33:51.000+0000 |
Description
On [Stack Overflow](http://stackoverflow.com/questions/36833477/invalid-swift-support-the-swiftsupport-folder-is-missing) a user reports his app was rejected with the following message:
{quote}
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.
{quote}
My guess is that since 7.3 we need
EMBEDDED_CONTENT_CONTAINS_SWIFT = YES
for the watch app extension target as well, not just the watch app (which was what Xcode did before).
https://github.com/appcelerator/titanium_mobile/blob/master/templates/applewatch/watchos2-swift/template/%7B%7BExtName%7D%7D.xcodeproj/project.pbxproj.ejs#L327-L386
Have we tried that? Can [~fokkezb] create a PR if that is a fix? :)
Hi Fokke I have tried as you suggested on SO and changed the Embedded Content Contains Swift Code to No in the SDK it makes no difference. The extension already has this set to Yes as it is a Swift project - also tried this with a new watchos2-swift extension just to make sure.
[~magnatronus] be aware that the extension had two targets and I suspect that contrary to what the template has you now need to set this flag on both targets. Can you verify you have?
https://devforums.apple.com/message/1042117#1042117 http://www.openradar.me/18389777 Basically, Xcode includes the SwiftSupport folder if you archive via Xcode. However, titanium uses *xcodebuild* from command line. And Apple *doesn't* include this folder if you use *xcodebuild*. This bug has been filed to Apple. Hopefully it'll be looked into soon. Otherwise, you can attempt the workaround in the links above. Basically you got to manually open the Xcode project in the Titanium build folder, and archive it.
So tried the suggestion from Fokke (watch extension target did not have the value set initially) and also then using Xcode directly (setting the Swift flag in the main project to both Yes and No - and each time the same Invalid Binary result. First time (with direct Xcode compile) Swift flag set to No (SDK default) the same missing folder issue. If the Swift flag is set to True then the result is Invalid Binary but the email is different. Dear developer, We have discovered one or more issues with your recent delivery for "xxxxxxxxxx". To process your delivery, the following issues must be corrected: Invalid Swift Support - The Watch OS application has Swift libraries at both /Payload/xxxxxxx.app/tips WatchKit App.app/tips WatchKit Extension.appex/Frameworks/ and /Payload/xxxxxxx.app/tips WatchKit App.app/Frameworks/. Remove all of the Swift libraries from one of the locations and resubmit your app.
For further reference with regards to removing all of the swift libs issue. https://forums.developer.apple.com/thread/17931 Of course, it's not great to open an archive, and change the content. But it's worth a shot.
[~cng] so I guess we'll have to wait for Apple to fix this? In the meanwhile, to be able to use that workaround (more easily) we need to fix TIMOB-19818
TiSDK master PR: https://github.com/appcelerator/titanium_mobile/pull/8375 TiSDK 6_0_X PR: https://github.com/appcelerator/titanium_mobile/pull/8376 TiSDK 5_5_X PR: https://github.com/appcelerator/titanium_mobile/pull/8377
[~cng] This ticket has no fix-version.
[~hansknoechel] It almost made it into 5.5.0, but was deemed to risky. It should go in 6.0.0, possibly 5.5.1. We need to extensively test my PRs above.
[~hansknoechel] Please help to review this. Otherwise I can take a look at a later time.
Upon investigation of this ticket, we found and fixed a number of small issues. However, we never actually fully reproduced this error. It could have been an issue with an old Xcode beta release. I tested with Xcode 8 and a Swift 3 watch app and I was able to successfully build and validate in the app store. So, I have moved the above PRs to TIMOB-23957 and we will resolve this ticket as cannot reproduce.
Chris, This is actually a big issue and it's really easy to reproduce: - include a swift framework - set EMBEDDED_CONTENT_CONTAINS_SWIFT=YES (which you should not remove if the project has embedded frameworks!) - archive and publish -> you get the response from apple. Now about the reason, it's quite simple, you create the xcarchive yourself and not using "xcodebuild archive". Thus the SwiftSupport is missing... The fix is quite simple, when building for testflight/appstore, simply call "xcodebuild archive" instead of "xcodebuild build", and remove the xcarchive creation from the package.js hook.
Chris, I was the one who originally submitted and talked with Fokke about this issue and the problem is not validating the app in the app store - that always worked the error only appeared after apparent successful submission with an email from Apple rejecting the app.
Yes Steve same here. And i just succesfully submitted a testflight build with the fix.
[~farfromrefuge] Oooooh. No way. OK, I'll look into this. The existing calls to
ditto
trace back to the old Python-based scripts before I worked on tooling stuff. I'll reopen and give your suggestion a go. Thank you for bringing this to my attention. :)[~cbarber] Just so you know switching to "xcodebuild archive" broke a few things. After doing so the .app creation was not fully working anymore and resources where missing from it. This is because because you create the .app and handled it all the way through. Now XCode handles it so you need to find a way to manage it after that. You can look at the commits in my fork to see how i did it. Bset
Good news! I fixed the iOS build so I'm now calling
xcodebuild archive
and it's bundling the missingSwiftSupport
directory. Ti SDK master PR: https://github.com/appcelerator/titanium_mobile/pull/8688 Ti SDK 6_0_X PR: https://github.com/appcelerator/titanium_mobile/pull/8689 Thanks [~farfromrefuge] again for nudging me to properly fix this! :)Looks good! PRs merged!
[~farfromrefuge] or [~magnatronus] We have done everything we can to test this short of submitting for review. We don't have an app on the QE team that we can submit, although we have plans to do so in the future and will be working on this very soon. If you have any positive results from app review using SDK 6.0.1.v20161217061750 please let us know.
Hi, apologies for the length of time to re-test this and reply, but I have today successfully submitted an app with Watch support to the app store that has not (yet) had a rejection email and is now awaiting review. I will post again when the app is released or rejected. The app was created from scratch using TISDK 6.0.1.GA.
The app was approved and is now in the app store - https://itunes.apple.com/us/app/watch-tips/id1205407902?ls=1&mt=8
Thanks for the update Steve, good to know everything works with latest SDK!
[~magnatronus] Congrats! Thank you very much for letting us know!
I'm actually having this same issue. Recieved that same rejection message yesterday. :( My app is NOT for the watch though. Just regular iPhone. I checked for updates within appcelerator, and there are none available. Xcode 7.3 SDK 6.0.1.GA Titanium CLI 5.0.11 Platform iphone END OF LOG: [...] [INFO] : Optimizing .plist and .png files [INFO] : Invoking xcodebuild [INFO] : Preparing xcarchive [INFO] : Archiving debug symbols: /Users/me/Documents/Appcelerator_Studio_Workspace/MFQ/build/iphone/build/Products/Release-iphoneos/MFQ.app.dSYM [INFO] : Launching Xcode: /Applications/Xcode.app [INFO] : Packaging complete [INFO] : Finished building the application in 33s 823ms
[~webtys] If you are doing an App Store build with 6.0.1.GA, then you should be OK. Please ensure that you have selected the correct SDK version in the tiapp.xml.
Yes, I did an app store build. Yes, the SDK version in tiapp.xml is set to 6.0.1.GA That's why this is confusing.
For the benefit of anyone else having this problem, is there a way to manually compile this properly from the command line, or from within Xcode?
Using SDK 6.0.1, Xcode 8 and tried to upload my app to App Store. Error is *not* about missing SwiftSupport folder but *'Invalid Swift Support - The SwiftSupport folder is empty. Rebuild your app using the current public (GM) version of Xcode and resubmit it. '* So looks like this is is the next stage of the bug where the folder exists but empty?
[~mallik.majety] Please build your app using Titanium SDK 6.0.3.GA and Xcode 8.3. You shouldn't have any issue publishing your app. :)
Hi Chris, Just tried with 6.0.3GA and Xcode 8.3. No luck and still getting the same response from Apple.Validation is going OK. Also, the generated archive did have the folders SwiftSupport/iphoneos but is empty. Is that expected? Are there any explicits flags to be set? Environment details from the console log if that helps: {noformat} Operating System Name = Mac OS X Version = 10.12.3 Architecture = 64bit CPUs = 8 Memory = 17179869184 Node.js Node.js Version = 4.6.0 npm Version = 2.15.9 Titanium CLI CLI Version = 5.0.11 Titanium SDK SDK Version = 6.0.3.GA SDK Path = /Users/xxxxxx/Library/Application Support/Titanium/mobilesdk/osx/6.0.3.GA Target Platform = iphone Command /usr/local/bin/node /Users/xxxxx/.appcelerator/install/6.1.0/package/node_modules/titanium/lib/titanium.js build run --platform ios --sdk 6.0.3.GA {noformat}
[~mallik.majety] Hmm, not good, looking into it.
[~mallik.majety] Can you please provide some more info? Does your app include a Watch App? Are you using Hyperloop? Are you using any Titanium modules? Are you building from Studio or from the Appc CLI?
Chris 1. No Watch App 2. No Hyperloop 3. Modules - I have a couple of 3 party ones like dk.napp.drawer etc 4. Building from Appcelerator Studio, build: 4.8.1.201612050850 Right now, exploring options on the Xcode side of things, but if you come across any solution that'd be great. Didn't see this coming!
[~mallik.majety] I think I figured out the issue. In the Titanium Xcode project template, we have "Always Embed Swift Standard Libraries" set to "yes". This is because of Watch App support and Hyperloop, which supports Swift code, so this flag must be set to "yes". However, if there is no Swift code, then perhaps this should be set to "no". Before I change the Titanium Xcode project to default to "no" and set the gears in motion to ship a new Hyperloop version, would you mind manually applying the change and see how it goes? The file we want to update is
~/Library/Application Support/Titanium/mobilesdk/osx/6.0.3.GA/iphone/iphone/Titanium.xcodeproj/project.pbxproj
. Make a backup of theproject.pbxproj
first, then open theproject.pbxproj
file in your favorite editor. There are 4 instances of build settings that reference "SWIFT". Set all 4 of them toNO
. Save the file. Rebuild your project for the App Store and submit the app. Since the Swift settings have been disabled, then hopefully theSwiftSupport
folder will not be required and your app will be published. Please let me know so we can get a fix out with 6.0.4. Thank you!!Hi Chris, That worked! Thanks mate, app is now uploaded to iTunes Connect.
[~mallik.majety] Awesome! I'll reopen this ticket and turn off the Swift settings. Thank you!
Titanium SDK master PR: https://github.com/appcelerator/titanium_mobile/pull/8944 Titanium SDK 6_1_X PR: https://github.com/appcelerator/titanium_mobile/pull/8945 Titanium SDK 6_0_X PR: https://github.com/appcelerator/titanium_mobile/pull/8946 To test: * Create a Titanium app * Do a dist-appstore build * Observe there is no "SwiftSupport" directory in the
.xcarchive
* Open the generated Xcode project, go to Build Settings, filter by "swift", and observe Swift settings are disabled * Add a watch app to the project * Add your<team-id>
to the<ios>
section of the tiapp.xml * Add thedist-appstore
provisioning profile uuid for both the watch app and extension * Build again for dist-appstore * Observe there is "SwiftSupport" directory in the.xcarchive
* Open the generated Xcode project, go to Build Settings, filter by "swift", and observe that only the Watch targets have Swift settings enabledValidate with this environment: Node Version: 6.10.1 NPM Version: 3.10.10 Mac OS: 10.12.4 Appc CLI: 6.2.0 Appc CLI NPM: 4.2.9 Appcelerator Studio, build: 4.8.1.201612050850 Xcode 8.2.1 Titanium SDK versions: 6.0.4.v20170410103627, 6.1.0.v20170412080612, 6.2.0.v20170414065620 Following the steps in Chris Barber's comment above, the fix is validated. Specifically here are my steps and observations: 1. Created a new app, and did a dist-appstore build. 2. Observed there was no SwiftSupport directory in .xcarchive (as expected). 3. Opened the generated XCode project and observed that Swift settings were disabled (as expected). 4. Added the watch app, and built again. 5. Observed that SwiftSupport directory is in .xcarchive (as expected) 6. Opened the XCode project and verified that only the Watch targets have Swift settings enabled. Swift settings for the main project was still disabled (as expected).
We just ran into this when using Xcode 10.1 and SDK 7.5.0.GA. Error: {quote} Invalid Swift Support - The SwiftSupport folder is missing. Rebuild your app using the current public (GM) version of Xcode and resubmit it. {quote} We use the Swift based [Ti.SocketIO](https://github.com/appcelerator-modules/titanium-socketio) module which injects the Swift compatibility via [this hook](https://github.com/appcelerator-modules/titanium-socketio/blob/master/ios/hooks/ti.swiftsupport.js). Can someone confirm how to workaround this?
Discard my above comment! Submitting it via Xcode Organizer instead of Application Loader resolved the issue.