I have filed the requested bug report with the minimal reproducing Swift IPA attached. Feedback ID: FB24633162

I performed the clean-project test suggested above. I created a completely new native Swift iOS project in Xcode 26.6, in a separate directory, with a new unrelated bundle identifier. It contains no Flutter, Kotlin Multiplatform, third-party frameworks, or code from our existing application. After: Product → Archive → Distribute App → Release Testing the exported IPA produces exactly the same result: SigningTest.app: valid on disk SigningTest.app: does not satisfy its designated Requirement Inspecting the designated requirement again shows the organization's à in decomposed form: 61 cc 80 while the actual Apple Distribution certificate contains the same visually identical à in precomposed form: c3 a0 I have also reproduced the same behavior using Xcode 26.0.1, 26.1 and 26.6. This therefore appears independent of our application, framework, bundle identifier, or project configuration. A brand-new Xcode-generated Swift application signed by the same team reproduces the issue. Hopefully this minimal reproduction helps isolate the issue.

I am seeing what appears to be the same issue with Xcode 26.6, but with the character “à” in our organization's name. App Store Connect rejects the upload with: ITMS-90035 – Invalid Signature Code failed to satisfy specified code requirement(s). I was also able to reproduce the problem locally by exporting the application using: Organizer → Distribute App → Release Testing and then verifying the exported application with codesign. The result is: MyApp.app: valid on disk MyApp.app: does not satisfy its designated Requirement After investigating, I found the same type of Unicode normalization mismatch described in this thread. In the actual Apple Distribution certificate, “à” is stored in precomposed form: à → c3 a0 while the designated requirement generated during distribution contains the visually identical “à” in decomposed form: a + combining grave accent → 61 cc 80 So the two values look identical but are represented differently internally, causing the application not to satisfy its own designated requirement. I would also like to emphasize that in our case “Sàrl” is not simply part of a company name that we can change to work around the problem. Sàrl (Société à responsabilité limitée) is an official legal form for companies in Switzerland, equivalent to forms such as LLC or Ltd in other countries. The Swiss government's SME portal states that there are more than 92,000 Sàrl companies in Switzerland and that the legal-form designation must be included in the company name: https://www.kmu.admin.ch/fr/forme-juridique-societe-a-responsabilite-limitee-sarl Our organization is officially registered as a Sàrl, so removing or replacing the “à” is not a viable workaround. This also means that the issue potentially affects a large number of Swiss companies using Apple's distribution tools. Previous versions of our application were successfully distributed under the same registered organization name using older Apple/Xcode signing toolchains. I am adding this information mainly to confirm that the issue is reproducible with another accented character and another organization, and that in the Swiss case the affected text is part of a standard legal company designation rather than an unusual organization name.