Hello

You uploaded a build containing debug information (.dSYM folder). This is used for live debugging and not for distribution. For TestFlight and App Store publishing you need to upload an .ipa file without such debug information (untick the relevant checkbox).

This hints me that I should probably change something so that the .dSYM folder is stripped out at code signing time when it's signed with a distribution certificate...

Let me know if you need more help.

Hmm, that's a new one. A few questions :

- Does the app work OK when deployed on a device ?
- What minimal target iOS version did you set ?

It's possible that Apple changed some rules now that the Swift libraries are widely deployed with the iOS updates and the ABI is stable, and I should now use the system-supplied Swift libraries instead of bundling the ones from the SDK with the app.

Before investigating that, I'd like to know the answer to these 2 questions (especially the 2nd).

:: @Pierre-Marie Baty added on 21 Sep ’22 · 17:15

*edit* Okay, I see a discrepancy anyway between Apple's guidelines and what the toolset does. As per https://developer.apple.com/documentation/bundleresources/placing_content_in_a_bundle the Swift system libraries should be embedded in a subdirectory of the app called "Frameworks". The builder does that in a subdirectory called "Libraries". It was accepted but it looks like it no longer is. I can already fix that.

Version 3.52 which I'm about to release should fix this issue. You can download it once it's packed up and uploaded (in a few hours).

You're welcome. Let me know if that wasn't enough for Apple to accept your build.

I found the reason here :

https://stackoverflow.com/questions/41907323/what-is-the-file-size-overhead-of-the-bundled-swift-libraries-compared-to-an-obj/41907555#41907555

It looks like the new builds that are sent to Apple also need to bundle *two versions* of their Swift libraries, one into the Frameworks folder of the app and the other one into a SwiftSupport folder inside the .ipa.

I have to update my makeipa.exe utility to reflect this change. Thank you for your patience...

My apologies. I've been very busy this week. I commit myself to give you something before monday.

What you can do in the meantime :

- re-sign your IPA file for distribution
- unzip your re-signed IPA with 7zip, preserve the directory structure.
- create a "SwiftSupport" directory just aside the "Payload" directory
- copy all the files that begin with "libswift" that are in the Payload/YourAppName.app/Frameworks directory inside the SwiftSupport directory (i.e. duplicate them there)
- re-zip your IPA (make sure to use the .zip format) and rename the resulting .zip file to .ipa
- last check: open it with 7-zip again to make sure the directory structure is preserved: at the root of your archive you should have two directories, i.e. "Payload" and "SwiftSupport". If that's okay you're good.
- upload the resulting .ipa file *WITHOUT resigning it*.

Let me know if this workaround does it.

OK. So my update wouldn't work because I was about to reuse the Swift libraries already re-signed as part of the IPA package. But as I understand they expect these libraries in the SwiftSupport directory to NOT be re-signed by your signing identity.

Alright, let's verify theory #2:

- re-sign your IPA file for distribution
- unzip your re-signed IPA with 7zip, preserve the directory structure.
- create a "SwiftSupport" directory just aside the "Payload" directory
- enumerate all the files that begin with "libswift" that are in the
- copy all the files that begin with "libswift" that are in the Payload/YourAppName.app/Frameworks directory; for each of them, *copy them from C:\Users\YourWindowsAccountName\iOS Project Builder for Unity\SDK\swift-5.0\iphoneos* to the SwiftSupport directory (i.e. duplicate them there)
- re-zip your IPA (make sure to use the .zip format) and rename the resulting .zip file to .ipa
- last check: open it with 7-zip again to make sure the directory structure is preserved: at the root of your archive you should have two directories, i.e. "Payload" and "SwiftSupport". If that's okay you're good.
- upload the resulting .ipa file WITHOUT resigning it.

Notice the change in bold and tell me what Apple say; did I get it correctly this time ?

:: @Pierre-Marie Baty added on 10 Oct ’22 · 14:26

*edit* looks like the caret slipped away while I was typing. The step that changes should be read like this:

- enumerate all the files that begin with "libswift" that are in the Payload/YourAppName.app/Frameworks directory; for each of them, *copy them from C:\Users\YourWindowsAccountName\iOS Project Builder for Unity\SDK\swift-5.0\iphoneos* to the SwiftSupport directory (i.e. duplicate them there)

To make it 100% unambiguous the procedure is like this:

- re-sign your IPA file for distribution
- unzip your re-signed IPA with 7zip, preserve the directory structure.
- create a "SwiftSupport" directory just aside the "Payload" directory
- enumerate all the files that begin with "libswift" that are in the Payload/YourAppName.app/Frameworks directory; for each of them, *copy them from C:\Users\YourWindowsAccountName\iOS Project Builder for Unity\SDK\swift-5.0\iphoneos* to the SwiftSupport directory (i.e. duplicate them there)
- re-zip your IPA (make sure to use the .zip format) and rename the resulting .zip file to .ipa
- last check: open it with 7-zip again to make sure the directory structure is preserved: at the root of your archive you should have two directories, i.e. "Payload" and "SwiftSupport". If that's okay you're good.
- upload the resulting .ipa file WITHOUT resigning it.

Let me know what Apple says this time.

That's instructive. We are making progress.

So, for Apple the code signatures are now correct, which means that the expected signatures were:
- The Swift libs in SwiftSupport should be signed with Apple's signature as they come from the iOS SDK
- The Swift libs in Payload/YourAppName.app/Frameworks should be signed with your signing identity

But now Apple tells us that they want the *binary contents* of those libraries to be identical. Which seems at first sight totally absurd since the Swift libraries from the SDK contain all the possible architectures (including the iOS Simulator) whereas those in the Payload folder of your IPA are thinned to just those your app explicitly supports, to save space.

Since we can't resign the Swift libraries from the SwiftSupport directory with Apple's signing identity (because we don't have it) they must stay untouched. Which means the libraries in Payload/YourAppName.app/Frameworks should *not* be thinned to keep just the supported architectures of your app. That seems to be what the following sentence indicates : _Don’t apply post-processing to /Payload/YourAppName.app/Frameworks/libswiftFoundation.dylib, /Payload/YourAppName.app/Frameworks/libswiftCoreGraphics.dylib, /Payload/YourAppName.app/Frameworks/libswiftObjectiveC.dylib, /Payload/YourAppName.app/Frameworks/libswiftCoreFoundation.dylib, /Payload/YourAppName.app/Frameworks/libswiftCore.dylib, /Payload/YourAppName.app/Frameworks/libswiftDispatch.dylib, /Payload/YourAppName.app/Frameworks/libswiftDarwin.dylib._

I'll need to modify the build script for that not to happen any longer. I'll publish a fix soon. Thanks for your patience.

:: @Pierre-Marie Baty added on 11 Oct ’22 · 23:44

*edit* The downside of this curious Apple requirement will be that the IPA files submitted to the App Store will be quite significantly bigger in size. It shouldn't affect the "final" app download size, as the post-processing which is no longer to be done by the build system will be done by the App Store themselves. But nonetheless, it looks like a waste of bandwidth to me somehow.

Just to update on this issue. I've been looking at the build script today and I realized that it does *no longer* embed the Swift libraries with the app. That was done a long time ago when Swift support was not ubiquitous among iOS devices, but now what the script merely does is instructing the app to look for the *system* Swift libraries in /usr/lib/swift. And it no longer embeds any Swift library at all.

So I'm not quite sure how these Swift libraries ended up in your Framework directory. Could you share your Xcode project with me so that I better understand what's happening ? Send it to pm @ this domain dot com. Confidentiality guaranteed.

@Oneday: I've sent you an e-mail with a link to a beta version that should fix your issue. Have you received it ?

:: @Pierre-Marie Baty added on 20 Oct ’22 · 08:42

*edit* Problem solved by e-mail. An update will fix the issue for everybody else.