Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

iOS Build Rejected Due to Missing SwiftSupport Folder (ITMS-90426) #30

Closed
sandaruwanWGMA opened this issue Feb 19, 2025 · 1 comment
Closed

Comments

@sandaruwanWGMA
Copy link

sandaruwanWGMA commented Feb 19, 2025

When submitting an iOS build to App Store Connect, the build gets rejected with the error "ITMS-90426: Invalid Swift Support - The SwiftSupport folder is missing." This happens while using Xcode 16.2 and Flex UI 1.2. The issue occurs because a .dylib file inside Embedded Frameworks is included when building the iOS app from Unity, which causes missing Swift library dependencies. The app should pass validation, but it fails due to this issue. I ensure that in Xcode ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES is set to YES in Build Settings too. This issue may be related to how Flex UI 1.2 handles Swift libraries in Xcode 16.2. A potential fix could be converting the .dylib files into an .xcframework, but this requires the header files (.h) of the .dylib files to properly expose the symbols and functions. Since these headers are not available, converting the .dylib to an .xcframework is not an option either.

@gilzoide
Copy link
Owner

A potential fix could be converting the .dylib files into an .xcframework, but this requires the header files (.h) of the .dylib files to properly expose the symbols and functions.

Headers are not really required for the project to build, so likely creating a .framework/.xcframework with just the dylib is enough. The apps with Flex UI package are building correctly only with the .dylib right now without any additional headers, right, and it works (it just isn't accepted by Apple when uploading the build).

Also, there's no Swift whatsoever in this package, my guess is that Apple is just assuming any binary is a Swift package and sending this message, but really we just need to repackage the binary properly, no need to mess with any more options in XCode.

Closing this because its a duplicate of #25, please let's focus the conversation there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants