Invalid Bundle error from iTC, cannot submit app - because 4 swift dylibs fail to embed

It took 12 hours to figure this out, but this is what fixed it -- changing the ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES build setting like this:

App target (main target) -- set to NO (mine was YES)

Watch target -- set to YES (mine was NO)

Watch App Extension target -- set to NO (mine was YES)

Edit: I figured this out by creating a new, empty watch project in xcode 8, and cross-referencing the differences between build-settings in the new xcode 8 template project, and my crusty old ancient project. The settings above are what the xcode 8 template project has.

I wanted to elaborate on my experience with this issue to hopefully save someone else some time if they run into this.

Background:

1. Older project originated with iOS 8, WatchOS 1.0 App and Today Extension
2. Updating app from Swift 1.0 to Swift 3.0.1, updated target iOS from 8 to 10, watchOS from 1.0 to 3.0
3. Started using Cocoa Pods with this refresh, wasn't originally

@xaphod had missing libraries, when I ran the otool -L all libraries looked correct in each of the targets.

After many rejected binaries I finally:

1. Uninstalled Cocoapods from the project, as suggested here
2. Updated Cocoapods to most recent, non-beta, version
3. Reinstalled Cocoapods, reducing pod targets from app, watch app, watch extension, today extension, and test targets to just the app (since the main app was only thing using pods)
4. Followed @xaphod suggestion posted here to create a new template project (without using pods) and compared build settings, particularly ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES
5. Set ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES

Main App Target=$(inherited) per Cocoa pods warning suggest. This defaults to YES and is actually displayed as YES - $(inherited) in Xcode. Lastly, EMBEDDED_CONTENT_CONTAINS_SWIFT = YES per pod settings which pods do for you

Watch App=YES

Watch Extension=NO

Today Extension=NO

Before the above settings, I attempted $(inherited) for everything to make cocoa pods happy. This clearly was a poor life decision.

I finally found attempting to export as AD HOC would fail if the binary wasn't going to be accepted by iTunes Connect, so I could save time testing theories before throwing the build at Apple. I attempted to compare a successful binary with a failing one but really didn't see anything in particular that stood out to me on the difference.

I still don't feel 100% comfortable with how I got this working but happy I could finally upload a binary. Cheers and good luck!

I was experiencing this issue in Xcode 10.1 recently and all my frameworks were referenced correctly. Seems there were some changes in the apple validation process, may be a bug, may not be on Apple's end, but all my prior builds uploaded and validated fine -- and I did not add any new frameworks since.

Upon uploading the binary to iTunesConnect, I'd see the following error:

Invalid Bundle - One or more dynamic libraries that are referenced by your app are not present in the dylib search path.

Invalid Bundle - The app uses Swift, but one of the binaries could not link to it because it wasn't found. Check that the app bundles correctly embed Swift standard libraries using the "Always Embed Swift Standard Libraries" build setting, and that each binary which uses Swift has correct search paths to the embedded Swift standard libraries using the "Runpath Search Paths" build setting.

SOLUTION: After days of debugging, what worked for me was to disable 'Include bitcode for iOS content' upon uploading the archive from Xcode organizer. Seems that this option modifies the binary which caused the validator to fail.