User Profile

We develop an SDK that is distributed as a statically linked, closed source Swift Package. Our customers have reported an issue when attempting to ship an application to the App Store using Xcode 15.3 that is preventing them from uploading the application: Asset validation failed Invalid Bundle. The bundle <AppName>.app/Frameworks/<Framework>.framework does not support the minimum OS Version specified in the Info.plist. (ID: 9cec9306-80a4-4503-a9bf-bd6e367f9679) Our SDK has a minimum deployment target of iOS 13.0 and the customer has a deployment target of 15.2. During local testing, I find that if my application and framework BOTH share the same deployment target of 13.0, then the App Store validation passes. If the application minimum version is greater than the framework minimum version, then the check fails. Researching on the internet, other people have suggested making the minimum deployment version of these Swift Packages to be GREATER than the app version. For instance, a handful of the Google SDKs shipped as binary packages on SPM are setting their minimum deployment version to 100.0 to work around this issue. I have tried this locally and found that if my app minimum deployment target is 15.2 and I set the MinimumOSVersion in the framework’s Info.plist file to 100, it passes the AppStore validation. It would appear that the check is inverted on App Store validation process. It is expected that an application can be submitted to the AppStore using a framework that works with older deployment targets. This issue appears to be related to the fact that Xcode 15.3 now embeds a .framework for statically linked framework dependencies. This is presumably done so that third party SDK's PrivacyInfo.xcprivacy can be included in the app package that it distributed to the app store. The binary portion of the statically linked library turns out to be much smaller (approx 35k) than the binary portion distributed in the .xcframework and appears to just be a small placeholder that does nothing since the actual code from the library is statically linked into the resulting application. The problem with the workaround that the other framework vendors have taken is that eventually (hopefully)  will fix this check and then these frameworks will appear to target a no existing iOS version. The other workaround that I spoke to our customer about was also extremely hackish and not really recommended was to resolve the Swift Package, then manually modify the contained Info.plist file to set the MinimumOSVersion in there to match what they are targeting for their application. This, however, then breaks the code signing of the SDK. So they then need to delete the _CodeResources folder from the resolved .xcframework. None of these work arounds are really sustainable and violate all the things right in the world. I have created feedback FB13704428 for this issue, but am hoping to raise further awareness as this is causing customers to not be able to ship applications using our, and many other, third party SDKs. Additional reading: https://github.com/google/GoogleSignIn-iOS/issues/375 https://github.com/google/abseil-cpp-binary/pull/6/files (If you examine the info.plist files in the two versions, you can see the minimum version set to 100 in the latest) https://github.com/AppsFlyerSDK/AppsFlyerFramework/issues/263 https://www.reddit.com/r/swift/comments/1bd7kxj/swift_ios_cannot_upload_to_testflight/