Using Pre-processor Macro,how to change file name for Development, staging and production Environment? - ios

Problem statement:- I am using third party library, which need to have config.plist(name must be same), Config.plist have several key-value pairs, for production,Dev and stating environment, values for key does change.
Right now i need to manually change file Name, like if i need to run app in production environment, i do change file name ConfigPROD.plist into Config.plist,
for Staging i do change file name from ConfigDev.plist into Config.plist.
Need Solution like:- can i change, file content using preprocessor macro, like
#if isProductionBuild == 1
#define kBaseURL #"https://api.base.com/bart/"
#define kEnvironmnet #"PROD"
***//copy ConfigPROD.plist file content into Config.plist***
#elif isStageBuild == 1
#define kBaseURL #"https://api-stage.base.com/bart/"
#define kEnvironmnet #"stg"
*//copy ConfigSTG.plist file content into Config.plist*
#else
#define kBaseURL #"https://api-dev.base.com/bart/"
#define kEnvironmnet #"dev"
*//copy ConfigDEV.plist file content into Config.plist*
#endif
pleae see if we do have feature like "copy ConfigDEV.plist file content into Config.plist"
Note:- This file copy operation should get completed before third party library start using Config.plist.

You don't need a preprocessor macro, you need a Run Script build phase that gets executed first. See Running a Script While Building a Product for an introduction. Just create a Bash script that looks at $CONFIGURATION (which will be Debug or Release or any other configuration name you have) and then renames one or the other file. Something like:
mv ./Config.plist ./Config.plist.orig
if [[ 'Release' == ${CONFIGURATION} ]]; then
cp ./Config.PROD.plist ./Config.plist
else
cp ./Config.DEV.plist ./Config.plist
To easily handle this, add all 3 files (Config.plist, Config.DEV.plist and Config.PROD.plist) to Xcode, but only the first one should be added to the target (check the box in the right side panel). You can have default settings in this file, it will be overwritten anyway.
If you're using git or something similar, you can add another run script phase at the end of your build to restore the original Config.plist to hide your changes from git.

Related

Xcode Localizable.string multiple targets issue

I have a project with multiple targets, which represent the same app just with different styling and translations.
Since almost whole project looks the same for each target, I need to have just few strings in Localizable.strings file, that I need to be different. And I don't want to copy whole huge Localizable.strings file to each project just because of the fact it has few lines different.
It is required for me to have just 1 strings file because of third-party libraries/SDK that are included in project. So I cannot use tableName for localizedString.
The problem is - I need to have a flexible possibility to override just few lines from Localizable.strings for each target separately. And I don't like the idea just to copy whole file to each target, cause it will lead to annoying flow in the future, in case I will have 10 targets and I need to add 1 string to all of them.
The goal is to have 1 huge Localizable.strings file with all strings included, that would be common for all targets, and have small configuration for each target for the strings that should tell different. So target's file should kinda merge and override the one that is common.
AFAIK it is not natively supported by Xcode, so I'm probably looking for a script that would make it works.
So, script should look into common and target's Localizable files, merge them, and in case some keys are defined in both, then it should use the one from target's file.
Can anyone help me with such script?
P.S. Similar issue exists with .xcassets, and CocoaPods solves it by merging multiple assets into 1, and it works as expected - if some targets has an asset containing the image with the same name that is already included into a common asset, then the one from target will replace it.
P.S.2. Similar feature is natively supported for Android devs - each image, each translations can be overridden by "child" flawor, or whatever it is called :)
TL;DR:
Example project: https://github.com/JakubMazur/SO45279964
OK, the easier thing to do would be shell/python script, because it will work for every build server. I assume that you have a different scheme for each target (otherwise it will make no sense). So what you can do is:
Let's say your target is named:
target1
target2
target3
1) Create separate files contains all the strings that should be different (i will put it under Localizable directory.
Your Localizable.strings file may look like this:
"someGeneralString" = "General string 1";
"AppName" = "This is a string that you probably need to change";
"someOtherGeneralString" = "General string 2";
And any of your targetX.strings file may look like this:
"AppName" = "target[x]"
And here is how it should look like in your project:
Note that your target localizable files should has target membership set only to one target, but your Localizable.strings should be for all targets!
That's all for project configuration. Let's go to scripting (I will use python for that):
#!/usr/bin/python
import sys
supportedLanguages = ["en","pl"]
commonPath = ".lproj/Localizable.strings"
keys = ["AppName"]
class CopyLocalizable():
target = ""
def __init__(self,arg):
self.target = arg
self.perform()
def perform(self):
for lang in supportedLanguages:
pathToLocalizable = lang+commonPath
textToFile = ""
with open(pathToLocalizable,"r") as languageFile:
for line in languageFile.readlines():
for key in keys:
if key in line:
textToFile += self.foundAndReplace(key,lang)
else:
textToFile += line
self.saveInFile(pathToLocalizable,textToFile)
def foundAndReplace(self,key,lang):
pathToTargetFile = "Localizable/"+lang+".lproj/"+self.target+".strings"
with open(pathToTargetFile,"r") as targetFile:
for targetLine in targetFile.readlines():
if key in targetLine:
return targetLine
def saveInFile(self,file,stringToSave):
with open(file,"w+") as languageFile:
languageFile.write(stringToSave)
You can optimize it yourself. It's easier script i can think about to get a job done.
And in the end let's automate it a bit:
- Go to your target
- add a new build phase
- Add a new script:
export PATH="/usr/local/bin:$PATH"
cd SO45279964/
python localize.py target[x]
and watch a magic happen ;)
http://www.giphy.com/gifs/26n6NKgiwYvuQk7WU
Here you can find example project that I've created to run this example:
https://github.com/JakubMazur/SO45279964
To keep it simple, Have a Macro defined for each target in Build Settings & define target specific strings within macro section like
#ifdef __TARGET__
//key values in localizable file
#endif

How do I display the CFBundleShortVersionString in my LaunchStoryboard?

Is there any way to display the CFBundleShortVersionString as a UILabel text in my LaunchStoryboard without entering it by hand every time it increments? I know how to do it in code, but it is not possible to run code while the LaunchStoryboard is shown.
Is it possible through Xcode variables?
As we all know, you can't put code in a launch screen. And unfortunately there isn't a built-in way to use a variable for a label's text in the launch screen (similar to how you can preprocess Info.plist with values in a header file).
The only option available to achieve your goal would be to write your own script that updates the LaunchScreen.storyboard file and add that script as a custom Build Phase for your target.
To make this easier, I would setup your target to use a preprocessor file for Info.plist. Once that is done and working, you now have a separate and simple header file you can interrogate in your script to process the LaunchScreen.storyboard file.
Here's a complete solution:
Create a file named Info.h and add it to the root of your project.
Add the following line:
#define APP_VERSION 2.6 // Update this version as needed
Now select your project's target in Xcode and go to the General tab. Change the Version value from whatever number you have there to APP_VERSION.
Now select the Build Settings tab. Search on Info. Under the Packaging section, set the Preprocess Info.plist File to Yes. Also set the Info.plist preprocessing Prefix File to Info.h.
Now when you do a build, the CFBundleShortVersionString value in Info.plist will be set to the value in the Info.h file.
To get the label in the launch screen file updated to match, do the following:
Select your launch screen storyboard and then select the label that will contain the version number. Show the Identity Inspector pane. Enter APP_VERSION into the Label attribute. If you look at the storyboard file now, the XML for the label will now show a userLabel attribute with the value of APP_VERSION.
Go back to the project target and select the Build Phases tab. Click the + icon and choose to add a New Run Script Phase. Rename the new phase to something useful like "Update Launch Version". Then drag the new phase to before the existing "Copy Bundle Resources" phase.
Now open the new "Update Launch Version" phase. Enter /bin/bash in the Shell field. Copy and paste the following code into the phase:
VERSION=`cat Info.h | grep APP_VERSION | cut -f3 -d' '`
sed -e "/userLabel=\"APP_VERSION\"/s/text=\"[^\"]*\"/text=\"$VERSION\"/" Storyboard.storyboard > tmp.storyboard
Now do a clean build. This is a test at this point. Have a look at tmp.storyboard and make sure it looks correct and the label for the app version is showing the proper version.
Once that is working, update the above code to:
VERSION=`cat Info.h | grep APP_VERSION | cut -f3 -d' '`
sed -i bak -e "/userLabel=\"APP_VERSION\"/s/text=\"[^\"]*\"/text=\"$VERSION\"/" Storyboard.storyboard
This final version actually updates the launch screen storyboard file. The previous version was a test to make sure everything else was working without risk to trashing your storyboard.
I figured out the script to update the Version & Build label on LaunchScreen.storyboard based on the first answer without using any extra files. Unfortunately, Clemens Brockschmidt's solution doesn't work due to some Syntax errors and incorrect paths.
Make sure to name your label to "APP_VERSION" in Identity Inspector pane -> Document -> Label.
Also create your script before "Copy Bundle Resources" phase.
UPDATE: My older answer didn't work in the newest Xcode environment. I've fixed the current issues and refactored the script.
And here's the final working script with shell: /bin/sh in XCode 11 (Swift 5):
# ON/OFF Script Toggle (script ON with #, script OFF without #)
#exit 0
# Increment Build Number Bool (Increment ON with true, increment OFF with false)
shouldIncrement=false
# App vesion / Build version constants
sourceFilePath="$PROJECT_DIR/$PROJECT_NAME/Base.lproj/LaunchScreen.storyboard"
versionNumber="$MARKETING_VERSION"
buildNumber="$CURRENT_PROJECT_VERSION"
# Increment build number
if [ "$shouldIncrement" = true ]; then
buildNumber=$(($buildNumber + 1))
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "$INFOPLIST_FILE"
fi
# Output version & build numbers into a label on LaunchScreen.storyboard
sed -i .bak -e "/userLabel=\"APP_VERSION\"/s/text=\"[^\"]*\"/text=\"$versionNumber($buildNumber)\"/" "$sourceFilePath"
As a BONUS I've included a build number incrementer and ON/OFF script toggle to disable your incrementer when you build your project a lot. Let me know if you have any issues or if this works for you.
Edit
There is no way to make the launch screen dynamic. Doesn't work good
with localizations too etc
A alternative is given below
Previous Answer
You should make your inital VC similar to the LaunchScreen.xib and in that make a label.
Now in the ViewController you can access the info plist through NSBundle method and set its value. This would make the transition from Launch screen to first VC smooth and look natural with version code animating in or something if you want
let appVersion = NSBundle.mainBundle().infoDictionary["CFBundleVersion"];
myLabel.text = "\(appVersion)"

Localize iOS App name in Unity

I'm'developing a Unity3D game that shows a different (localized) app name in the iPhone's home screen according to the user local language. Note that:
I already know how to localize the iOS app name by editing the Xcode project (create a InfoPlist.string file, localize it, add the CFBundleDisplayName key to it, etc.)
I also know how automatically localize an Android app name within the Unity editor (add a values-XX.xml file with the app_name property onto Assets/Plugins/Android/res/ folder, etc.)
The question is: how can I automatically localize my iOS app name within the Unity Editor so that I don't need to perform the error-prone task 1. every time I build the project?
I think that PostprocessBuildPlayer should be the way to go, however I haven't found any documentation on how to parse it and/or modify the Xcode project file correctly to achieve this.
Long time ago I ran into trouble when I tried to modify info.plist via the Build Player Pipeline especially when doing it in Append mode. It works only once and then subsequent builds fail with "The data couldn’t be read because it isn’t in the correct format." (s. Unity forum posts like this one and my blog posting about this problem) So I decided to take the alternative way combining a customised build with an Xcode Build Pre-action.
Three steps are required:
(1) Xcode setup:
In Xcode go to Edit Scheme / Build / Pre-actions. Then click the + sign to add a New Run Script Action.
In Provide build settings select Unity-iPhone.
Paste . ${PROJECT_DIR}/modify_info_plist.sh (note the dot and blank at the beginning, is ensures that the script is executed in the caller's shell)
So it should look like this:
(2) Script modify_info_plist.sh:
Within your script you have access to all environmet variables from Xcode (s. Xcode Build Setting Reference) and you can manipulate Info.plist using the defaults command (man page). Here is a sample I used to add gyroscope to the UIRequiredDeviceCapabilities:
# Code snippet used in Unity-iPhone scheme as "Build Pre-Action"
my_domain=${PROJECT_DIR}/Info.plist
status_bar_key=UIViewControllerBasedStatusBarAppearance
logger "Start adding keys to info.plist"
defaults write $my_domain $status_bar_key -boolean NO
if [ `defaults read $my_domain UIRequiredDeviceCapabilities | grep "gyroscope" | wc -l` = "0" ]; then
defaults write $my_domain UIRequiredDeviceCapabilities -array-add "gyroscope"
fi
logger "Keys added to info.plist successfully"
(3) Build Pipeline:
Put the following code in a static editor class to create a new menu item Tools / My iOS Build with shortcut cmd+alt+b:
static string IOSBuildDir= "Develop";
[MenuItem("Tools/My iOS Build %&b")]
public static void IOSBuild () {
string[] levels = { "Assets/Scenes/Boot.unity",
"Assets/Scenes/Level-1.unity",
// ...
"Assets/Scenes/Menu.unity"
};
string path = Directory.GetCurrentDirectory ();
path += "/" + IOSBuildDir + "/Info.plist";
if (File.Exists (path)) {
Debug.Log ("Removing file " + path);
File.Delete (path);
}
BuildPipeline.BuildPlayer (levels, "Develop", BuildTarget.iPhone,
BuildOptions.AcceptExternalModificationsToPlayer);
}
I know this is no perfect solution but it's the only one I found to work stable. Two drawbacks:
Step (1) has to be repeated after major Xcode format changes
New scenes have to be appended in the editor class code in step (3)

Xcode 5: Set symbolic breakpoints programatically

Symbolic breakpoins are great, but it's a hassle to manually add then in xcode. Well, after you add one, you can just enable/disable them, but it would be nice to be able to do it in code... something like this:
#if DEBUG
SetBreakPointForFunction([Myclass myfunction], BreakPointActionPlaySound);
#endif
Is this possible?
https://developer.apple.com/library/ios/recipes/xcode_help-breakpoint_navigator/articles/setting_breakpoint_actions_and_options.html
Not in code exactly, but you might be able to create breakpoints during the debug build phase with a shell script (Or have the shell fire python, ruby, whatever… to do the work.)
If you peek inside the .xcodeproj folder, you'll see it has paths like:
[projectName].xcodeproj/xcuserdata/[userName].xcuserdatad/xcdebugger/Breakpoints_v2.xcbkptlist
[projectName].xcodeproj/xcshareddata/xcdebugger/Breakpoints_v2.xcbkptlist
(disclaimer, this example references xcode 5.1.1)
The contents of the files are fairly straightforward:
<?xml version="1.0" encoding="UTF-8"?>
<Bucket
type = "4"
version = "2.0">
<Breakpoints>
<BreakpointProxy
BreakpointExtensionID = "Xcode.Breakpoint.SymbolicBreakpoint">
<BreakpointContent
shouldBeEnabled = "No"
ignoreCount = "0"
continueAfterRunningActions = "No"
symbolName = "-[ActivitySpanner thresholdTimePassed]"
moduleName = "">
</BreakpointContent>
</BreakpointProxy>
</Breakpoints>
</Bucket>
So, by stuffing instances of BreakpointProxy into one of these files, you might apply a library of favorite breakpoints. Duplicates could be a pain, either push and pop the file or check for the instance first.
At worst, if xcode can't be forced to re-read the xcbkptlist files when they are changed by your script, then you could have a script that manipulates the breakpoint files, and then opens the project. (Perhaps overkill, we've gotten into the territory of continuous integration tools like Jenkins now :)

how to set the path to where aapt add command adds the file

I'm using aapt tool to remove some files from different folders of my apk. This works fine.
But when I want to add files to the apk, the aapt tool add command doesn't let me specify the path to where I want the file to be added, therefore I can add files only to the root folder of the apk.
This is strange because I don't think that developers would never want to add files to a subfolder of the apk (res folder for example). Is this possible with aapt or any other method? Cause removing files from any folder works fine, and adding file works only for the root folder of the apk. Can't use it for any other folder.
Thanks
The aapt tool retains the directory structure specified in the add command, if you want to add something to an existing folder in an apk you simply must have a similar folder on your system and must specify each file to add fully listing the directory. Example
$ aapt list test.apk
res/drawable-hdpi/pic1.png
res/drawable-hdpi/pic2.png
AndroidManifest.xml
$ aapt remove test.apk res/drawable-hdpi/pic1.png
$ aapt add test.apk res/drawable-hdpi/pic1.png
The pic1.png that will is added resides in a folder in the current working directory of the terminal res/drawable-hdpi/ , hope this answered your question
There is actually a bug in aapt that will make this randomly impossible. The way it is supposed to work is as the other answer claims: paths are kept, unless you pass -k. Let's see how this is implemented:
The flag that controls whether the path is ignored is mJunkPath:
bool mJunkPath;
This variable is in a class called Bundle, and is controlled by two accessors:
bool getJunkPath(void) const { return mJunkPath; }
void setJunkPath(bool val) { mJunkPath = val; }
If the user specified -k at the command line, it is set to true:
case 'k':
bundle.setJunkPath(true);
break;
And, when the data is being added to the file, it is checked:
if (bundle->getJunkPath()) {
String8 storageName = String8(fileName).getPathLeaf();
printf(" '%s' as '%s'...\n", fileName, storageName.string());
result = zip->add(fileName, storageName.string(),
bundle->getCompressionMethod(), NULL);
} else {
printf(" '%s'...\n", fileName);
result = zip->add(fileName, bundle->getCompressionMethod(), NULL);
}
Unfortunately, the one instance of Bundle used by the application is allocated in main on the stack, and there is no initialization of mJunkPath in the constructor, so the value of the variable is random; without a way to explicitly set it to false, on my system I (seemingly deterministically) am unable to add files at specified paths.
However, you can also just use zip, as an APK is simply a Zip file, and the zip tool works fine.
(For the record, I have not submitted the trivial fix for this as a patch to Android yet, if someone else wants to the world would likely be a better place. My experience with the Android code submission process was having to put up with an incredibly complex submission mechanism that in the end took six months for someone to get back to me, in some cases with minor modifications that could have just been made on their end were their submission process not so horribly complex. Given that there is a really easy workaround to this problem, I do not consider it important enough to bother with all of that again.)

Resources