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.
Related
I have been using Info.plist in my projects, but recently I noticed that freshly generated new projects don't contain them anymore, and Info.plist is instead generated by Xcode at build time, from Info.plist Values section in target's Build settings.
I like this, as it would allow me to ship two projects (beta and non-beta one) from a same folder, without special build steps modifying the Info.plist for each project.
However, I noticed that:
Many Info.plist keys are missing in Build settings (eg. ITSAppUsesNonExemptEncryption, or NSLocationAlwaysUsageDescription/NSLocationUsageDescription/NSLocationWhenInUseUsageDescription), so I cannot set them from there. There also doesn't appear to be any + sign when hovering, which would let me add another key into that section.
And the way of adding INFOPLIST_KEY_ITSAppUsesNonExemptEncryption = NO; into a .pbxproj file, which I have found documented somewhere, no longer works.
Is there a way of adding additional keys into generated Info.plist? Or, is there a way of having both both Info.plist file in a filesystem, and Info.plist Values section in build settings, and make Xcode merge them during build?
Here is how the section looks like:
So, this was helpful (thank you Andrew!), but the core insight I got from experimenting is:
Xcode doesn't want to let you enter invalid keys in places they don't belong.
Build Settings only have basic properties, anything else belongs into the 'Info' section. Editing it will create a new Info.plist file with only the changed properties, which will then be merged with info.plist keys from build settings (I couldn't find a documentation for build order).
Some settings, like ITSAppUsesNonExemptEncryption for standalone watch-only apps have no place to go.
Apple mostly abandoned standalone watchapps, there is a ton of bugs around them and they don't care.
I am currently working on an iOS project in XCode that uses configurations to specify the different API environments my app can connect to. Additionally, I use targets to override one of my project configuration's user-defined values to specify a particular configuration file to use in the app. However, this is the only value that changes in the target. I work with multiple different configuration files (maybe 10 to 20 at a time) and creating a new target for each file to update one value seems clunky.
My question: Is there a way to pass this one value in from the scheme instead of setting it in the target?
I have seen that there is a pre-build script that can be run but I have not yet had any success exporting environment variables.
CONFIG_FILE="My Config File"
export CONFIG_FILE
I have also seen that some people have had success using PlistBuddy to write the values into the info.plist file during the pre-build phase of the scheme. This may be an option as well although it would require I redo a lot of my build process. I wanted to see if there was any other options before heading down this path.
Thanks for the help.
I was able to do this by using a .xcconfig file that is updated during my pre-build action in my scheme.
I used this tutorial to learn how to set up the project: http://www.jontolof.com/cocoa/using-xcconfig-files-for-you-xcode-project/
I am trying to create an app with multiple targets so I can use the code for different apps with small changes. I managed to work with many variables needed by setting custom keys in plist file and making user-defined-settings entries for referencing them. The problem is that with Facebook SDK I cannot do that. I have set a custom key in plist like ${FACEBOOK_APP_ID} and a user defined setting on my target like FACEBOOK_APP_ID with my app's id in it. When I compile and run, I get app_id is required error (of course if I hardcode it on plist works fine). Does anyone know of a solution not requiring to use different plist files for each target?
After struggling for days with that without a good solution, I found that if I set preprocess info.plist to Yes, I can add user-defined settings to build-settings as usual and they are available at runtime. Now, I only have to enter the three variables to the target configuration and there is no need for a preprocess file or preprocess macros.
Update:
I have added FACEBOOK_DISPLAY_NAME, FACEBOOK_APP_ID and FACEBOOK_URL_SCHEMES to user defined settings (from Editor->Add Build Setting menu in Xcode) with the proper details for each target. Then In Info.plist (I use one globally for all targets) I added the options Facebook SDK guide states but instead of static values I added ${FACEBOOK_APP_ID}, ${FACEBOOK_URL_SCHEMES}, and ${FACEBOOK_DISPLAY_NAME}. Then on build settings I chose YES to preprocess plist file. Now I can change the info in my user-defined settings for each target and works ok (without the need of an extra preprocess file and the need for defining macros)
You can try use the macro in your difference target, in the code you just define the value by the macro. exampe:
#if project1
//the app id const
#endif
I have a project that I maintain for a client; let's call it MyDataAssistant. When the project goes into beta, the client likes to have a "separate app" built for them, which I create using a different provisioning profile and a modified bundle identifier (MyDataAssistant-BETA). It's a pain to always be going back and forth and changing the bundle identifier, code signature settings, and especially the icon. I understand that you can have multiple targets and multiple build settings (within each target?) in a project, but I'm not clear on what the difference is, or how to use them appropriately.
Additionally, the client would like a third version with read-only capabilities. I can accomplish this by just making a flag return from a certain part of my code, but I would like it if that flag could be toggled in the build (target?) settings.
Please advise on how to manage this kind of project with multiple "variations" of the build.
Add a new configuration to your project by duplicating the release one for example.
Give it a name "Beta"
Add a User-defined build setting
Call it MY_DATA_ASSISTANT_BUNDLE_ID_SUFFIX for example and set the value to be -BETA only for the Beta configuration.
Edit the MyDataAssistant-info.plist file by setting the bundle identifier to com.YOURCOMPANYNAME.MyDataAssistant$(MY_DATA_ASSISTANT_BUNDLE_ID_SUFFIX)
This will make it have different values for the different configurations.
You can also set the display name to have a different value by setting it to $(PRODUCT_NAME)$(MY_DATA_ASSISTANT_BUNDLE_ID_SUFFIX)
Set the right provisioning profile for each configuration. (Of course after creating the beta one in the provisioning portal as if it was for a new app with the bundle identifier having the suffix "-BETA")
Create a new scheme!
Give it a name: MyDataAssistant-BETA
Change its build configuration to "Beta" for all the actions and you should be ready to go.
If you want to have different icons for the beta version you can use the $(MY_DATA_ASSISTANT_BUNDLE_ID_SUFFIX) in the MyDataAssistant-info.plist file for the icons names and of course add them to the target.
I would recommend creating two targets. This will allow you to share what files you want between variations, as well as have custom source, or config files in each. The simplest implementation of this would be to have an identical target except for the info.plist file.
Simply right click on your current app target in project settings, and hit duplicate.
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.