Upload to App Store failing after update to to version 8.0.0

[seamlink-aalves]

Bug Report

Problem

App with special characters in name gives an error when submiting to the App Store after updating to cordova ios 8.

The same App with name without special charaters is able to be sbmited with no errors.

What is expected to happen?

I should be able to publish with no errors

What does actually happen?

I'm able to archive the app correctly but when publishing to the App store I get error:

Validation failed (409)
Missing or invalid signature. The bundle '......' at bundle path 'Payload/<name with special characters>.app' is not signed using an Apple submission certificate. 

Information

I control the App name by changing the CFBundleDisplayName in info.plist with:

<config-file target="*-Info.plist" parent="CFBundleDisplayName">
            <string>My App</string>
</config-file>

The name node in config.xml falls back to a safe name. In previous cordova-ios version this worked fine. In the new version the App get's the name which is set in name node of config.xml.

Due to this, I now have set the name to the name with special characters and stopped editing the CFBundleDisplayName but the upload fails with the error above.

Command or Code

Environment, Platform, Device

MacOS Latest

Version information

cordova ios 8
XCode 26

Checklist

• I searched for existing GitHub issues
• I updated all Cordova tooling to most recent version
• I included all the necessary information above

[seamlink-aalves]

After further investigation I was able to upload the App to the App Store with the following steps:

• The App is created by Cordova with Display Name, Bundle Display Name and Product Name with the name set in config.xml (all with the same value with special chatacters)
• I openned the App in XCode and in Build Settings edited Product Name to "App"
• This automatically changed Bundle Display Name to the same value as Product Name
• I then changed Bundle Display Name to the Display Name (with special charecters) which did not change Product Name

With this changes I was able to upload sucessfully to the App Store.

This only works if the Archive process is done through XCode. If I build it through the command line it reverts to the previous configuration.

I created a hook to remove INFOPLIST_KEY_CFBundleDisplayName from the pbxproj file on after_prepare, but the build command recreates the pbxproj file.

It seems to me that having Product Name as "App" as no impacting on the naming shown in the App store and on the device and should solve this issue.

Can someone else confirm this?

[seamlink-aalves]

I finally managed to find a workarround after checking PR #1485 . I used the shortName property to set the naming with special charaters because the algorithm checks if the short name is different from the name and uses it in that case.

However, I think this should be looked at, because the name should not break the upload process to the App Store.

[dpogue]

The file name of the project and resulting binary have no relation to the displayed app name in the App Store or when installed on devices. In cordova-ios 8, the project name was made "App" consistently, specifically to resolve issues relating to project names with Unicode characters that were causing problems for CocoaPods, plugins, and build tools.

For setting the application name and on-device display name, that should be entirely possible through the config.xml <name> element. You should not need to do any manual config editing or hook-based modifications of the Info.plist file.

[seamlink-aalves]

I think I did not make myself clear. If the name element has special characters it will not fail to build but it will fail when uploaded to the app store with the error mencioned in the initial report.

I was only able to upload it if I use the short property for the name with special characters while keeping the name element without special characters.

This is easely reproduceble if you try using characters like á à é ç in the name.

[dpogue]

Ah, thanks for clarifying. That does seem like an issue that needs further investigation.