Considering to iOS development, The Internet contains a lot of materials on “How to do applications”, but much less about effective work organizing. Development is not only about writing ideal code. It’s a good idea to minimize the time spent on programming related tasks. Some tricks, automation and using hidden (actually, most of them are not hidden) powers of your IDE can save you up to one hour a day.
Server API based applications usually need to use different API endpoints for different purposes. For instance, you have Production, Development and Staging endpoints. Each of which has different configs set. Let it be
loggingLevel. These configs should be different for each environment.
Usually programmers deal with it by commenting and uncommenting values in config file. Config file then looks kinda like this:
As you see, we are now on Development environment :) It’s dirty, messy and error-prune. We need a convenient and safe way to work with different environments.
Using the Xcode schemes seems to me as the logical and convenient method to deal with multiple environments. First of all, create the new project using Single View Application option. I named my project MultiEnvSample.
At first, let’s create needed build configurations. Click project icon, select the project in the PROJECT section, click + icon. (fig. 1).
In the popup select which of the available configurations you want to duplicate. Duplication saves you from setting up configuration from scratch. I have created three configurations:
Production – duplicates
Development – both duplicates
Debug. (fig. 2)
Go to the upper left corner, press the button with your apps name (to the right of the Stop button), create new build scheme for each configuration. For the purpose of convenience, I gave them the same names. (fig. 3)
To hide the unwanted scheme from the list, select Manage Schemes from the schemes menu. Uncheck unwanted scheme. (fig. 4)
For each of your schemes repeat the following steps:
Select scheme and hit Edit Scheme menu option. (fig. 5)
In the next window select Run section, and select build configuration with the same name, as the scheme has. (fig. 6). Remember, that using this menu, you can always set up different options for each of your build configuration.
Now schemes configuration is over. Let’s add some code. Go to your
Info.plist file. Add new
String key, call it
$(CONFIGURATION) as the value. (fig. 7)
The last step needs some additional explanations. To build the app, compiler accepts different settings. These settings are listed in the Documentation. Or, if you want to see just a list, you can do it here on StackOverflow. The
$(CONFIGURATION) variable stores the name of the current configuration.
To test it select, for instance,
Development scheme from the list in the top left corner of the XCode. Then go to
AppDelegate.swift and modify
application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) method as it shown on the sample below. Run the project.
Test if it works for all the others configurations. In case of errors, check if you followed all the steps above.
Create new Swift class. Call it
Config. Add the following code to
Config.swift. This class is one of few rare cases, when Singleton is needed.
Let’s add some helper methods to get config values.
Now config properties are available from any place of your code.
Remember, that data in the
*.plist file can be readed and is potentially unsafe! (thanks @jcampbell_05 for friendly reminder). Yet, you can create config for the secrets in the code, and then store just the key in the
*.plist using the same access principle.
It’s always a good idea to prevent errors at the very start of the development. Using some simple techniques we can improve development quality, make routine tasks less painful and save the time.