Rename generated Xcode project to "CordovaApp" or something consistent

[dpogue]

Feature Request

Motivation Behind Feature

Currently, the generated Xcode project uses the application name for both the project and the target name. This means that file paths in generated projects are not consistent and we have to do regex-based token replacements during project creation. It also makes modifying the template project a pain because opening the template project directly in Xcode causes a bunch of those tokens to break.

The deeper problem is that some tooling (notably Cocoapods) struggles with project and target names with non-ASCII characters. By making the project name consistent, we can hopefully avoid those problems.

This could potentially also solve long-standing issues around <config-file> and <edit-config> for things like the Info.plist (currently named {{projectname}}-Info.plist) and node-xcode corrupting other targets due to not being able to restrict changes to just the app target.

Feature Description

The generated Xcode project would be named App.xcodeproj or CordovaApp.xcodeproj. The application target within that project would be named App or CordovaApp.

Prior Art: Capacitor projects are named App.xcodeproj with a default target named App.

Alternatives or Workarounds

The current method mostly works (as long as you don't have non-ASCII characters in the project name), so there's a valid argument for keeping the existing behaviour.

The workaround for now is to generate a project with an ASCII name and then override the app's display name, which is pretty much what this change would accomplish by default.

Ref https://github.com/apache/cordova-ios/issues/717. Ref https://github.com/apache/cordova-ios/issues/1150. Ref https://github.com/apache/cordova-ios/issues/1289.

[erisu]

I think having a consistent project name is a great idea.

Beyond the issues caused by non-ASCII project names, I've also heard of cases where hook scripts were needed to modify something within the project workspace. However, because the project name was inconsistent, they had to parse directory paths to extract the project name. A consistent project name would simplify this process.

It would also help clean up some of the node side in Cordova-iOS.

[Mrkvozrout]

Hi, I am currently also searching for a possibility to define (or just have) a simple technical project name instead of using app name.

Using app name as technical identifier is really not ideal because its purpose is to be a human readable display name for the target audience (with all those spaces and special characters).

In my use case it gets even worse because we have one app codebase for several different app variants where each variant needs to have different name (and package name and bundle ID and other identifiers). We use before_prepare hook to update these values in config.xml which works ok, but then e.g. the xcode project name is also always changing for each of the variant which makes working with it not ideal.

My current workaround (I am working on now) is to have simple stable <name> value as a project name and having several other hooks and edit-configs in order to update the real app name in all native platforms. A bit tedious and not ideal.

My solution proposal would be either of these:

1. add <project-name> element into config.xml
   • its value would allow to define stable simple project name used as technical identifier where needed (e.g. xcode project)
   • if not defined, the value would be taken from current <name> element's value
2. add another attribute to <name> element
   • e.g. <name short="Short App Name" long="Long Name of My App">my-app-project-name</name>
   • the short attribute currently exists and is used as human readable app name in short contexts
   • similarly add new long (or app) attribute to be used as human readable app name in common contexts
   • if not defined, the value would be taken from current <name> element's value

I favour option 2) more because all naming would be defined in single element and it just extends current ability to define short name.

Also the advantages of both options are:

• backward compatibility - if new element/attribute is not defined, the behaviour is the same like current/older cordova build logic
• having the ability to define custom simple project name (e.g. to better differentiate projects in IDE)

What do you guys think? @dpogue @erisu

[erisu]

@Mrkvozrout you might want to take a look at PR #1485

The above PR is refactoring to make the name of the app template/Xcode project consistent and will be hard set to App. E.g. App dir, App.xcworkspace, & App.xcodeproj, App-Info.plist, etc...

The name element will remain the same <name short="Short App Name">Long Name of My App</name> but wont be used for defining any of the project file names or directory names.

[Mrkvozrout]

I saw it and understood but thought that custom project name might be useful and offered solution.

Anyway the fixed project name is simpler and sufficient (and I guess it is consistent with the android's app gradle subproject).

So good for me and lets hope your PR is merged and delivered soon :)

[Mrkvozrout]

Question about the PR - Will "dynamic" change of name (<name> element value in config.xml) work as expected?

Expectation - if I update the name via hook early enough (before_prepare or before_platform_add), the new name should be used as the application name (on all needed places in the project in order to be visible after installation to device).

I tried to change the name in before_platform_add hook, which feels to be early enough for ios platform to not perceive it as a dynamic change, but I still get this error: The product name change (<name> tag) in config.xml is not supported dynamically.

To be answered:

• Will app name change work with this PR?
• Is next release the 8.0.0? (if yes, what it the expected rough release date?)
• Will there be some intermediate 7.x release? (if yes, I would create an issue to allow app name change in before_platform_add hook)

Thanks for answers in advance

[breautek]

Question about the PR - Will "dynamic" change of name ( element value in config.xml) work as expected?

That check will be removed allowing name changes across builds (without removing and re-adding the platform) via https://github.com/apache/cordova-ios/pull/1485/files#diff-3f506429799383a7a5415e9eef05bc14959c37346194ecd50394ea404b64487aL265

Is next release the 8.0.0? (if yes, what it the expected rough release date?)

It is being treated as a breaking change, among several other improvements so it will be part of a 8.0.0 released, assuming #1485 does indeed gets merged. Due to the volunteer nature of Apache Cordova project we can't reliably give any timelines.

Will there be some intermediate 7.x release? (if yes, I would create an issue to allow app name change in before_platform_add hook)

Unlikely because the repo is already in a 8.0.0-dev state, meaning it likely has breaking changes already merged.

As a workaround for the time being...

In my workflows I have config.xml gitignored and is generated via tooling based on the environment I want to build for (e.g. different app ids & name for staging vs production). Switching environments does involve removing the platform, run a script to generate a config.xml for the specific enviroment and then re-add the platform. This works since the config.xml is updated before calling on any Cordova tooling. It's not most efficient workflow especially if you're requiring changing environments frequently but it works for current versions of Cordova.