I have a confounding problem. I have built a swift package from an C++ library that uses a mix of static and dynamic libraries. The binaries have been wrapped in in individual xcframework frameworsk using xcodebuild -create-xcframework -library <....>.
Seemingly everything was working fine, no errors reported in XCode, the app builds to the device, and can be deployed through our CI with ad-hoc distribution. Building an archive works, and the local validation passes.
But when we came to submitting our app to the app store, appstoreconnect refuses the binary with the message
ITMS-90426: Invalid Swift Support - The SwiftSupport folder is missing. Rebuild your app using the current public (GM) version of Xcode and resubmit it.
No matter what tricks I do, I can not get this missing folder to generate.
That package consists of 2 static libraries, which in turn, depend on 3 dynamic libraries, there's an additional target for obj-c bridging code, one for some swift helpers on top, and a resources package.
The issues seems to be that the dylibs are not properly embedding. I've separated out the dylibs into a separate sub library product, and I'm trying to set the type of the product to .dynamic.
Issue 1 is that it will not let me specify the type if the targets are only binaries, xcode seem to think it will properly detect the type of the library and act accordingly, apparently it does not and just treats them as static libraries.
I can add a dummy target with just 1 source file to the library product, and then I can specify the type as .dynamic, then in my xcode project for the app, I am given the option to embed the library. That doesn't seem to be any use though, as despite an additional .framework folder for the library in the Frameworks folder of the archive, there is no SwiftSupport folder, and the dylibs are still placed in the root of Frameworks (Not in the created .framework folder)
I'm a bit confused as to the requirement of the SwiftSupport library, if it is required, how come our app has been building successfully already, and it is only app store connect rejecting it?
Why does XCode treat a package containing only dylibs as a static package (no option to embedd)?
If I trick it into actually treating it as a dynamic library, why aren't the dylibs in the created .framework folder?
This library is actually pretty important to us, it's a core tool we use across the business and it took quite some work to just get it built for ios, and it's frustrating to find, even though we thought we had the problems solved, it gets rejected at the last hurdle.
Any hints on what to do? I'm starting to guess I need to add an additional build phase to do something.