Hello

Interesting report, I just got another one today for the same problem. Does your app use Swift code ?

Well, did your project compile files ending in .swift ?

Open the build.log file at the root of your Xcode project to find it out.

If the upload gets stuck, closing it and restarting it is the right thing to do. It happens sometimes when the network is congested.

Maybe yes. Please open the master build script build.cmd in the builder's install directory with a text editor, and look for these lines:

% build.cmd around line 3800
	rem // NOTE: before 20220922, we added just the necessary rpaths. It's much simpler to add the common ones systematically.
	echo /usr/lib/swift>>              "!TARGET_BUILD_DIR!\rpaths.txt"
%

Change them to:

% build.cmd around line 3800 after the changes
	rem // NOTE: before 20220922, we added just the necessary rpaths. It's much simpler to add the common ones systematically.
	findstr ".swift$" "!TARGET_BUILD_DIR!\swift-srclist.txt" > nul && (
		rem // 20231116 - only add this rpath if we actually built Swift code in this target, else App Store Connect will mistakenly believe that the app uses Swift
		rem // without being able to guess the Swift version, and end up claiming that the Payload/SwiftSupport folder doesn't exist with the old Swift dylibs in it.
		echo /usr/lib/swift>>              "!TARGET_BUILD_DIR!\rpaths.txt"
	)
%

Rebuild your app thoroughly (tick the "rebuild once") checkbox, upload it and let me know what Apple says this time.

Sorry, I have no workaround at the moment. I'm waiting for other people's feedback to decide what to do.

:: @Pierre-Marie Baty added on 18 Nov ’23 · 18:41

*edit* If you have the possibility to build your app with Xcode, then please do so, upload it to App Store Connect (this is guaranteed to work) and send me the two generated .ipa files (the one created by Xcode and the one created by the builder) so that I can binary compare them. Thank you in advance.

:: @Pierre-Marie Baty added on 18 Nov ’23 · 19:23

*edit 2* I've just had an idea. Allow me the night to try it out, I'll report back.

Okay. The workaround I gave you in post #7 is ineffective in your case because your app, although it does not contain Swift code, did compile an empty Swift file, because that's the way these Xcode projects are made, and that was enough for the build script to believe it needed the /usr/lib/swift search path, which triggers the error (in my opinion).

Instead of adding the /usr/lib/swift search path if there were compiled .swift files (because these files may be empty) it is necessary to add it only if the final binary contains actual references to Swift functions in its symbols table.

So a better workaround that could work would be this instead:

% build.cmd line ~3800
	rem // NOTE: before 20220922, we added just the necessary rpaths. It's much simpler to add the common ones systematically.
	"!TOOLCHAIN_PATH!\nm.exe" -a "!OUTDIR!\!OUTFILE!" 2>&1|findstr "_swift" > nul && (
		rem // 20231116 - only add this rpath if we actually built Swift code in this target, else App Store Connect will mistakenly believe that the app uses Swift
		rem // without being able to guess the Swift version, and end up claiming that the Payload/SwiftSupport folder doesn't exist with the old Swift dylibs in it.
		echo /usr/lib/swift>>              "!TARGET_BUILD_DIR!\rpaths.txt"
	)
%

Unfortunately I don't have the possibility to test this today so please do so if you can and please report whether it works.

Have you increased the build number ? If you upload your ipa using the same build number than a previous upload, App Store Connect will discard your new upload and reuse the old one. This can be misleading because you receive an email that is not about the file you uploaded but about a previously uploaded one.

This error makes no sense. Why on Earth would Apple complain that a SwiftSupport directory is missing if your apps do not use Swift code ?

I've read a lot on this subject and it happens that sometimes this error does not mean what it says. It can be triggered by a stale hidden file at the wrong place (e.g. .DS_Store, thumbs.db, .gitkeep and similar.) But in order to find out what Apple dislikes, it would be necessary to compare an .ipa file created by Xcode and one created by the builder. Can either of you do that and send them to me (preferably, because it'll be signed by you), or send me his Xcode project so that I try to build it myself (less preferable, since I'll use my own signing identity at the risk of causing discrepancies) ?

Well, I built your test project with Xcode, created an archive of it, exported it for distribution to the App Store (without uploading) and the generated .ipa file does not contain any SwiftSupport directory either.

The zip contents of the .ipa package contains a single Payload directory, in which the app directory "IOS TEST Swift Support.app" is the only subdirectory.

If Xcode does not create this directory, how can the App Store claim it's missing ?

I'll upload it now to my Apple developer account and see what Apple says. Then I'll proceed the same with an .ipa of the same project built by the builder. It'll have to work, or to tell why.

I am still investigating it. Xcode makes it extremely painful and this IDE certainly deserves an award for its particular design. Thank you for your patience.

I think I found the problem.

This project does not use Swift, but it does use il2cpp.

And the version of the Unity editor you use supplies macOS executables for the il2cpp compilation step, and copies them in a subfolder of the Xcode project directory. These macOS executables are supposed to be called by Xcode in a "custom build step" phase to compile the il2cpp static library that your project will use.

The problem is that these macOS executables are provided in two variants (Intel and ARM64, to support all Mac's hardware architectures, Intel and Apple M1/M2) *and* rely on dynamic libraries that are written in Swift.

So, the builder parses the Xcode project directory, discovers these files, identifies them as ARM64 Mach-O libraries, and thinks: this iOS project supplies precompiled ARM64 binaries, I should take note of those and include them in the final application. And so it does.

Consequently your final .ipa gets extra files embedded in it, which are useless from the iOS app's point of view because they aren't iOS libraries but *macOS* libraries, that doesn't prevent the app to run (these extra files are simply ignored), but when Apple receives them on App Store Connect for analysis, they do the same mistake as me: they believe these libraries are useful for the app (for what else could they be here?), identify them as Swift libraries, deduce that the app uses Swift code, check whether the SwiftSupport directory is present... and fail.

The "quick and dirty" solution, in your case, is to use a pre-packaging script that contains these lines (WARNING: THIS HACK IS ONLY VALID IF YOUR APP DOES NOT EMBED ANY DYNAMIC LIBRARY):

% prepkg.bat
rem // delete the extra il2cpp host compiler libraries that were mistakenly bundled in the app by the build script
del /f /q "%TARGET_BUILD_DIR%\%NAME%.app\Frameworks\lib*.dylib"
%

Now, if you rebuild your app, you should notice that the .ipa size is smaller as it doesn't contain those extra files, and there are chances that, if you bump the build number as well, Apple will accept your build on App Store Connect. Let me know please.

Meanwhile I'll be looking for a more "proper" way of fixing this.

You can put it anywhere. Simply load it in the builder UI so that it is called during the build process.

Very glad to hear that !

A more proper fix will be in the next update.