deguchi commented on issue #1590:
URL: https://github.com/apache/cordova-ios/issues/1590#issuecomment-5390774499
Environment: cordova-ios 8.1.1, Xcode 26.6 (17F113), macOS 26.5.2 (Apple
Silicon). Our `<name>` in `config.xml` is `さばとマップ` and has not changed since
2018.
### The error is about resource sealing, not certificates
This is the exact text Xcode 26.6's Organizer returns:
```
Missing or invalid signature. The bundle 'jp.calil.sabatomap' at bundle path
'Payload/さばとマップ.app' is not signed using an Apple submission certificate.
code = 90034
```
**The "submission certificate" wording is actively misleading.** I spent
half a day chasing certificates and provisioning profiles; all of it was fine
from the start. The app is signed by an `Apple Distribution` certificate,
Apple's own OCSP responder reports it as `good`, `get-task-allow` is `false`,
the embedded profile is the App Store one, and the chain has no expired links.
What is actually broken is this:
```
$ codesign --verify --deep --strict "さばとマップ.app"
さばとマップ.app: a sealed resource is missing or invalid
```
Reading `_CodeSignature/CodeResources` shows why. **The main executable is
sealed as an ordinary resource:**
```
files2: 'さばとマップ' → hash2 does not match the file on disk
```
`codesign` fails to recognize the double-byte-named executable as the
bundle's main executable, so it seals its hash as a regular resource. The
signature is then embedded into that same binary, its bytes change, and the
sealed hash can never match. This is not an artifact of unzipping the IPA — the
app inside the `.xcarchive`, which never went through a zip, fails the same way.
Renaming is enough to make the causation unambiguous. Same archive, same
certificate, only the name differs:
| Bundle name (with `CFBundleExecutable` changed to match) | `codesign
--verify --deep --strict` |
|---|---|
| `さばとマップ.app` | a sealed resource is missing or invalid |
| `Sabatomap.app` | valid on disk / satisfies its Designated Requirement |
Worth noting: Xcode's own distribution logs mix both normalizations for this
bundle — `\U3055\U306f\U3099...` (NFD) in some places and `\U3055\U3070...`
(NFC) in others. Normalizing `PRODUCT_NAME` to one form does not appear to be
sufficient.
### Workaround, and the side effect it has on Android
Put an ASCII string in `<name>` and move the real name into the `short`
attribute. cordova-ios maps `<name>` to `PRODUCT_NAME` and `short` to
`CFBundleDisplayName`, so only the executable name becomes ASCII while the home
screen still shows the Japanese name:
```xml
<name short="さばとマップ">Sabatomap</name>
```
`CFBundleIdentifier` is untouched, so this is still an update to the
existing app. `codesign --verify --deep --strict` passes and the upload goes
through.
**This workaround breaks the Android name, though.** cordova-android puts
`<name>` into `app_name` and `short` into `launcher_name`, and
`AndroidManifest.xml` points `application` at `app_name` — so the app list in
Settings ends up showing the ASCII name. It can be corrected from the same
`config.xml`:
```xml
<platform name="android">
<edit-config file="AndroidManifest.xml" target="/manifest/application"
mode="merge">
<application android:label="@string/launcher_name" />
</edit-config>
</platform>
```
`activity` and `intent-filter` already reference `launcher_name`, so this
restores every label to the Japanese name. Verified with `aapt2 dump badging`:
`application-label: 'さばとマップ'`.
### Request
Japanese, Chinese and Korean app names are not unusual, so **I would like
the default behaviour to just work.** As it stands, a developer has to invert
the meaning of `<name>` and `short` to get iOS signing to pass, and then patch
Android back with `edit-config`. That is a lot of knowledge to demand for an
entirely ordinary requirement. `PRODUCT_NAME` is never visible to users, so
pinning it to a sanitized ASCII value costs nothing.
If the plan is instead to wait for `codesign` to change, **a warning from
`cordova build ios` when `<name>` contains non-ASCII characters would already
help a great deal.** Both the build and the archive succeed today, so CI cannot
catch this — you only find out when App Store Connect rejects the upload.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
