I created four different build configurations to my xcode project, they are QA, STAGING< UAT<& PRODUCTION. I use 4 different urls each for one build i created.
Now my question is xcode 4 is very good at detecting DEBUG mode as there is already predefined macro available, but How can I detect my custom builds so that i can pass different urls for different builds configurations?
In each one of those build configurations go into build settings and add a #define THIS_IS_QA=1 then test for it in your code and use it as you would use the DEBUG macro
The preprocessor macro route works alright and is quick to implement. But it does not scale well since you will end up with copies of each variable. The route I find works the best is to do the following.
Define the configuration as a User-Defined Setting in the project or target build settings.
Doing this allows for different values to be specified for each build configuration (eg. Debug or Release or even a custom one)
Create an information property in the projects plist file.
This allows the build setting to be accessed through the plist.
Write the code once to load the value form the plist file.
Example:
In the project create a User-Defined Setting called "BASE_API_URL" and set the debug configuration to "http://www.test.example.com" and the release configuration to "http://www.example.com".
Then in the plist create a new information property with the key of "BaseAPIUrl" and the value of "$(BASE_API_URL)"
Lastly in the app delegate where you define the base url add the following code:
let baseUrl: NSString = NSBundle.mainBundle().infoDictionary?["BaseAPIUrl"]! as NSString
Related
After googling a lot regarding my need, I finally ask to this awesome community a way to achieve my goal.
I need to create a swift library with cocoapod, and integrate multiple build configurations. I want to create 3 schemes on my project to switch easily environments variables (like target API, log level, and many more).
I really want to do this on library side, not on app-side, since it's for debug & testing purposes, and finally, applications which embed this pod will only use the "Release" build (except us, developers who maintain this library)
I tried opening the _Pods.xcodeproj and doing update in this file (create *.xcconfig files I need, mapped to configurations schemes) but disappear after ran a "pod install".
Not sure at all if you can do that hack on library side. Looks weird.
But the best practice would be:
When initializing and configuring libraries, endpoints etc (all you need to change between schemes), just check which one is used, and pass different parameters
create a file, FE Constants
struct Constants {
static var libraryApiKey: String {
#if DEBUG
return "debugKey"
#else
return "productionKey"
}
And when initializing
Library.initialize(withKey: Constants.libraryApiKey)
I need to create two different versions of the app.
- debug
-prod
for debug, version i need user to select the test environment before anything else begins. i need some way to know what environment user has selected and then load API endpoints config file accordingly.
what's the best way to handle this in flutter?
I have seen in some apps that for iOS, debug options are available in app settings under the standard iOS settings menu , select the app and then see those options in there.
You might want to use Flutter Flavours. As the name suggests, you can practically make flavours of the same app based on your need - debug, test, production etc. And not only API end-points, but you can also configure everything else such as app icon, different labels on the screen etc.
As suggested in this link, you can have different main.dart file for each flavour. You can read different configuration from JSON file (such as API end-point) and rest of your app will remain same. For example, see below :
This is another helpful link.
The ToString() method of
CKContainer.FromIdentifier("iCloud.com.My-Company").PrivateCloudDatabase
results in this string
<CKDatabase: 0x7ca335b0; databaseScope=Public,
container=<CKContainer: 0x7fd630c0;
containerID=<CKContainerID: 0x7ca33910;
containerIdentifier=iCloud.com.getvalid.CloudKitAtlas,
containerEnvironment="Sandbox">>>
I'm unable to locate "ContainerEnviornment" in any child or parent object.
Where is ContainerEnviornment located?
I want to have some custom logic behave one way in SandBox, another in Production.
The CloudKit container environment is determined at run-time using your app's com.apple.developer.icloud-container-environment entitlement.
There is no easy, built-in way to query this on any of the CloudKit objects.
If you'd like to browse your CloudKit data, you can use CloudKit Dashboard.
If you want to display some additional/different data in your debug builds, you can detect whether your app is a debug or release build, and condition your debug-only display on that.
For Swift:
Open your Target's Build Settings > Swift Compiler - Custom Flags.
Add "-DDEBUG" to the Debug section under "Other Swift Flags".
Then, surround your Debug-only code with:
#if DEBUG
// debug only code
#endif
I have built a generic application which can handle different content data - but for each content data, it will be a different iphone application (with a different name).
I would like of couse to only keep one code base for all these different apps (as it would be easier maintenance) but I have 2 questions:
1- I would need to change the appname in the buildsettings, etc.. and may be it is going to be an overkill...? especially with the upload process then...? What are your experiences in that domain and what would you recommend me to do?
2- how can I have all the pictures for logo (Icon.png, etc...) to co-exist into one app? For the moment, I have a global variable (as a singleton pattern) that I switch to change appname and loaded data inside the program
Thanks in advance for your help
Cheers,
geebee
You can do this pretty easily, it's what most developers do in their lite versions. All you have to do is add another target to create a new app out of the same code and use that global variable.
In order to change the images included in the app you simply edit the target and under the copy bundle resources menu remove the unnecessary resources. You'll notice that when you add a new resource you have the option to include it in any one or more of your targets. Simply select the one that you want and it will only be accessible to that target.
The reason that this works is that each target can have its very own info.plist. All the settings and resources can be separate, and the code can be different using your #ifdef global_var.
Here's a slightly outdated tutorial that should get you started if you need it.
http://www.bit-101.com/blog/?p=2098
For each application name add one target.
Create one xyz-info.plist for each of the target. (in this case for the xyz.app)
In each of the xyz-info.plist assign the appropriate icon files etc.
Within your build phases for each of the targets you will define which images go with which app.
What I am trying to achieve is for the application icon to be different in builds that I send out to my beta testers, to that of the application that will be submitted for approval. This will allow me and my beta testers to easily identify the app is a beta version.
I was not sure if I should be adding a build script to modify the info.plist and change the application icon specified there. For this I guess I would have to conditional check the build type (DEBUG/RELEASE/DISTRIBUTION etc) and write the appropriate value to the plist file.
Alternatively I thought I might need to create a separate target for beta releases and specify the new BETA application icon there.
If anyone has done this kind of procedure before, any tips and ideas about how best to do it would be very much appreciated.
Outdated: As of September 2017, my answer is probably outdated now. Please use latest Apple developer guides relating to Asset Catalogs. Asset Catalogs are the new way of specifying image/icon resources for your app.
Original answer:
Both ways you have mentioned can be used for this purpose (Through a separate Target or using Build settings). In my opinion, the more logical way would be to use a different build configuration and set the plist file to dynamically get the icon file name from the build configuration.
Here is how I would do it:
In project build settings, create a new user-defined variable called ICON_FILE (for "All Configurations")
Set the value of the variable to "Icon.png" (for "All Configurations")
Create a new build Configuration called "Beta".
Set the value of the ICON_FILE variable to "Icon-beta.png" for "Beta" configuration.
(this will make all the configurations have the value "Icon.png" except Beta config)
In the Info.plist set the value of "Icon file" attribute to ${ICON_FILE}. This will make the info.plist dynamically get the filename from the variable you defined earlier.
In your application resources, include the beta icon with the name "Icon-beta.png" in addition to "Icon.png" you already have.
If you build the app using "Beta" config, the app will have the beta icon as the app icon.
Hope this helps!
Asset catalogs can be used without creating another target.
Here are the steps I use:
1 - Create two (or more) app icon set in images.xcassets
2 - Create another configuration from project settings
3 - Go to Target -> Build Settings and search for app icon.
You will see Asset Catalog App Icon Set Name under Asset Catalog Compiler - Options. Change the asset catalog name that will be used in new configuration.
4 - Build for different configurations.
The accepted answer is not working for xcassets.
So, if you already started to use xcassets catalog here is the steps:
You need to create 2 different targets of your application.
To do this:
Right click on your target. -> Click Duplicate (or Cmd+D)
Set name of new target like MyApp-beta
Create separate icon:
Go to your xcasset catalog.
Right click on column with list of images -> click New App Icon
Name it like icon-beta, add place here your beta icons
Click on your beta-target
Go to tab General -> App Icons -> select your asset icon-beta
Here it is. Now you can build your beta application!
Another advantage of this method over that described in the accepted answer - is that you can install both versions at the same time of your Application. (you need to set different Bundle Identifier for this).