-
Notifications
You must be signed in to change notification settings - Fork 984
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor!: Consistent app template/Xcode project name #1485
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1485 +/- ##
==========================================
- Coverage 81.56% 80.89% -0.68%
==========================================
Files 16 16
Lines 1888 1842 -46
==========================================
- Hits 1540 1490 -50
- Misses 348 352 +4 ☔ View full report in Codecov by Sentry. |
a110c49
to
7bcd9b3
Compare
Otherwise when Xcode consolidates the plist file it will probably overwrite the ones in the plist with the ones defined in the Xcodeproj file (which is where it wants to put things by default nowadays).
Some plugins look up the root group of the Xcode project based on the name "CustomTemplate", which isn't really an ideal thing to do but I'm unsure if there are better options and this name doesn't actually get displayed anywhere so we might as well keep the label for compatibility reasons.
This is a guard against running a newer version of Cordova iOS tools against an older project with a different name (which will fail due to now-hardcoded assumptions about the project name).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Built & launch mobile spec test app. Ran test against default plugins.
Platforms affected
iOS
Motivation and Context
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.
Possibly closes GH-664.
Mostly closes GH-717 (still impacted by CocoaPods/CocoaPods#7546).
Possibly closes GH-764.
Probably closes GH-793.
Closes GH-795.
Closes GH-826 (due to not needing to do dynamic Info.plist lookups).
Closes GH-955.
Possibly closes GH-1049.
Closes GH-1150.
Closes GH-1289.
Closes GH-1464.
Description
Remaining work:
PRODUCT_NAME
to the config.xml name value so that the resulting app/ipa file has the expected namePRODUCT_BUNDLE_IDENTIFIER
in a better way at create-time to avoid token replacementWill handle as a follow-up PR:
App-Info.plist
to justInfo.plist
Testing
All unit tests pass.
Tested manually with mobilespec.
Tested manually installing
onesignal-cordova-plugin
in a project with both ASCII and non-ASCII names (ref GH-1289)Tested manually installing
cc.fovea.cordova.openwith
in a project and confirmed it built (ref GH-955)Checklist