How to localize app name for with different build configurations? - ios

I have a project that have 3 build configurations: Debug, Beta and Release. These configurations have different app name each. I am doing this using a variable like APP_DISPLAY_NAME and using it in Info.plist file.
I need to localize these app names.
Using InfoPlist.strings file with "CFBundleDisplayName", overrides these configuration names.
So how can I do this?
I have checked this and a couple more questions but still no result.

Here's how you can have different InfoPlist.strings for different build configurations in the same target.
In your Build Settings:
Specify a different Info.plist File (INFOPLIST_FILE) for each configuration.
Set Adjust Strings File Names for Info.plist (STRINGS_FILE_INFOPLIST_RENAME) to Yes. On Xcode 14, it was set to Yes by default.
Create .strings files with the base name of your Info.plist filename + Plist.strings.
For example, if your Info.plist filename is Beta-Info.plist, your strings file should have the name Beta-InfoPlist.strings. Make sure you include all of these strings file to your build.
Do not include an InfoPlist.strings file in your target.
The key to making this work is Adjust Strings File Names for Info.plist in the Build Settings Reference.
Adjust Strings File Names for Info.plist.
Setting name: STRINGS_FILE_INFOPLIST_RENAME
If enabled, renames .strings files whose basename matches that of the target’s Info.plist file, to InfoPlist.strings in the built product.
Example
Here's an example in my app which has 3 different variants (AdSupported, AdSupported-Dev, Pro) that require different app names.
Build settings. (I have debug & release configurations for each variant, but you could also do this with just Debug / Beta / Release.)
Strings files. They are all included in my target.
Info plist files. As usual, they are specified in the Build Settings and NOT included in my target.

Related

Access one targets Plist from Another target

I am currently trying to unify my targets inside of my application.
I have one codebase I build multiple versions of the app, all tailored to a different client using targets.
That said, I want to unify the build number and versions so when I write code and archive, all the apps are built with the same version/build numbers.
Can I have all the target plist files reference the main target plist for these numbers, so I do not have to go into each target and increment them?
Or should I have my appDelegate update its own target when archiving?
From what I understand you have multiple targets under the same project, and you want all the app's that the targets build to have the same version (that you set in one place). It is not so easy to read them from one info.plist, but it is easy to have one build setting variable that all the info.plist use.
Simply go to the info.plist for each of the targets and replace the value of the version with a variable value e.g. ${APP_VERSION}:
The go to the project's build settings and add a user defined value with that name:
and give it the value of the version you want:
Now the info.plist will have the version you set in one place(the APP_VERSION build setting), you can do the same for the other info.plist files so that all read the same value.

Xcode - Changing Bundle Display Name By Language

I want my app name to be localized(English and Simplified Chinese). I localize the Info.plist in my project and added Simplified Chinese. So I have two Info.plist files now. Error occured when I build the project. "Info.plist could not be found". So I edited the path of Info.plist at Build Settings > Packaging > Info.plist File Path. Now it worked.
The problem is that at Build Settings > Packaging > Info.plist File Path , Xcode only seeks for one Info.plist. If I change the path to zh-Hans.lproj/Info.plist It would only display Chinese App Name on both English and Chinese Language Settings. And the same goes when I change it to en.lproj.
How can I set the path of the Info.plist so that xcode could recognize that there are two of them that needs to be used according to Language setting?
Or is there any better way than what I am doing?
Many Thanks!
You don't localize Info.plist itself, you put localized strings in a separate file InfoPlist.strings. Quoting Apple:
Localized values are not stored in the Info.plist file itself. Instead, you store the values for a particular localization in a strings file with the name InfoPlist.strings. You place this file in the same language-specific project directory that you use to store other resources for the same localization. The contents of the InfoPlist.strings file are the individual keys you want localized and the appropriately translated value. The routines that look up key values in the Info.plist file take the user’s language preferences into account and return the localized version of the key (from the appropriate InfoPlist.strings file) when one exists. If a localized version of a key does not exist, the routines return the value stored in the Info.plist file.
In the specific case of the display name, each localized version of InfoPlist.strings would contain something like
CFBundleDisplayName = "My Cool App";
and the display name in Info.plist would be used only if it is not overridden in InfoPlist.strings.

Localize Info.plist with XLIFF in Xcode 6

Problem
I cannot figure out how to localize the NSLocationWhenInUseUsageDescription key. During export of the base language XLIFF file, Xcode automatically includes CFBundleDisplayName, CFBundleName, CFBundleShortVersionString, and NSHumanReadableCopyright. How can I include additional Info.plist keys? When I try to edit the strings files directly, the added keys are not included in future XLIFF exports.
Background
I am using the new base internationalization and localization tools in Xcode 6. With it, you no longer create or edit .strings files. Rather, choose "Export for Localization" from the "Editor" menu. Xcode will create an XLIFF file with strings from all nibs, code, and Info.plist. You then import a translated XLIFF, which then creates all strings files automatically, including InfoPlist.strings. See Localizing Your App from Apple's documentation.
You need to manually create an InfoPlist.strings file, and add it to the en.lproj folder in the project directory in the Finder. Then drag it into the Xcode project with the other InfoPlist.strings files without copying it.
Please Note:
The InfoPlist.strings file will need to include the default keys and the keys you wish to add.
The file should NOT be added to base.lproj. This is reserved only for xib and storyboard related files.

info.plist for different target version

One of my project needs to provide lite/full version and english/french version.
I know that localise and set info.plist/InfoPlist.strings for different luanguange.
But if I also hope to set the info.plist for different target version(lite/full).
How can I do?
When you create a new target Xcode will make a copy of the info.plist for the new target. In the target build settings you can even change the name of the info.plist used for that target.
The default name of the info.plist is something like copy-info.plist when you rename the file on the file system make sure that you also rename it in the build settings. The build setting key you need to change is Info.plist File.

Info.plist and its variables like ${APPNAME}

I am preparing Info.plist for my iOS application. I want to carefully set each option. However, there are some weird variables like ${REGION}, ${APPNAME}, ${EXTRA_ICONS}, etc. I guess they are set via Xcode?
I don't want Xcode to mess with the values. Can I simply set them? For example, for ${REGION} insert "en". For CFBundleDisplayName – nothing, because the docs says:
If you do not intend to localize your bundle, do not include this key
in your Info.plist file. Inclusion of this key does not affect the
display of the bundle name but does incur a performance penalty to
search for localized versions of this key.
And so on. Can I simply do this? What to insert for "CFBundleExecutable"? I guess I have to know what Xcode generates?
This is horrible design, as there are two sources of values: the plist itself, and some stupid meta-plist inside Xcode.
Your Info.plist file is processed by Xcode thanks to the "Expand Build Settings in Info.plist Files" (INFOPLIST_EXPAND_BUILD_SETTINGS) Build Setting of your Project.
That's usually a great feature, as it avoids to have a different Info.plist depending on your build settings and configuration, and avoids you to modify the settings in multiple places. But if you really don't want it, simply turn this settings off in the Build Settings of your project or target.
I suggest you keep this setting on anyway, so that the values chosen in your build settings will be reported in your Info.plist, and if you need to change stuffs like the application name for example, change it in the Build Settings directly. This way you will keep consistency between your build settings and your Info.plist file, instead of risking to have an inconsistent configuration.
A great example is the one you wrote yourself in your own question : the CFBundleExecutable entry of the Info.plist file. This entry typically have to contain the name of the executable in your bundle (so that iOS knows which executable to launch inside your .ipa bundle).
This value typically depends on your Build Settings, typically the EXECUTABLE_NAME build setting. If you ever change the name of the generated executable (in the Build Settings of your project or target) and you did put some constant string for this value in the Info.plist, you obviously need to change this CFBundleExecutable key to the new name of the executable generated by Xcode. If you use ${EXECUTABLE_NAME} as the value for this key (and kept the processing of your Info.plist turned on in the project settings), Xcode will replace it for you, ensuring that the Info.plist is consistent with your Build Settings and with the name of the executable it has generated.
I don't see any advantage of disabling this processing phase of the Info.plist file by Xcode ; you should take advantage of it and keep using the ${xxx} build variables so they are replaced by their real values Xcode dynamically at compile time thus ensuring consistency and avoiding errors.

Resources