When developing an application, mobile app developers most often follow the standard development life cycle pattern – development, testing and production. For each of these stages, we have different API environments. For instance, when the app is in the development stage, it will communicate with development.api.com. Testing and production each have their respective API environments, too. In this article, we will discuss how to use Xcode targets to put a proper iOS app build system in place.
Creating separate API environments for development, testing and production provides each built with its own database, code-base and other respective backend services. This allows developers to continue to work and make changes, even while the app is in testing mode, and ensures (beta) testers do not mess up the production database.
We create a Constants.swift file in the project and define a variable called baseUrl. When building the app for development or production, we change the value of this variable so that the respective API endpoint is used in the build, as shown below.
(Commenting & Un-commenting the baseUrl per the build environment.)
Though this process is quick and simple, it is also highly error prone due to the following reasons:
To avoid these issues and create a more sound build system, one can use Xcode targets. If you aren’t familiar with targets in Xcode, read about them here before continuing.
Step 1: Create a Target
We will need to create a new target for each of the API environments. Technically, Xcode doesn’t allow you to create a new target, so we will duplicate (Cmd + D) the default target and rename it, as shown below.
(Creating a duplicate target.)
Xcode will automatically create a new scheme for this target.
Step 2: Setting Custom Flags
To change the API endpoint based on the build target, first you’ll need to set a custom flag. Based on this flag, your code can update the variables accordingly.
(Updating the DEBUG flag to DEVELOPMENT.)
These settings will impact how your app uses respective environment variables when your app is compiled.
Step 3: Using Custom Flags
Open your Constants.swift file, use the DEVELOPMENT flag as shown below, and set your environment variables (like baseUrl) accordingly.
As seen in the image above, you can define all the environment variables that should be different for development, testing and production.
Step 4: Testing
Now, let’s do a simple test to verify that the baseUrl changes per the build settings.
(Setting the Run Scheme to Debug.)
(Verifying log to see that the baseUrl displays the DEVELOPMENT API endpoint.)
(Setting the Run Scheme to Release and verifying log.)
That’s how we use Xcode targets to manage iOS builds with multiple API environment endpoints. Pretty easy, right?
If you install the development, testing, and production iOS builds on a single device all at once and test the builds, take note: After you have created a new target (by duplicating), you’ll need to enter unique values for the Display Name and Bundle Identifier, because no two apps on a device can have the same ones. To easily differentiate between the builds, you can use a different display name and app icon, as shown below.
(Development and Production builds on same device.)
To create these for each target build, go to BuildSettings, search for icon and change the value of Asset Catalog App Icon Set Name to the desired app icon file name.
Note: You must be cautious when adding new files, dependencies (pods) and iOS permissions in plist and CI systems. Be sure you are selecting all the targets you have created so that these files are compiled for all the targets, avoiding compiler issues.