When you think about changing an app’s behavior, the first question that comes to mind is, “What code changes should I make?” As you’ve learned, changing code isn’t the only way to change what your app does.
By the careful composition of your project’s schemes, settings and configurations, you can change how Xcode builds your app.
In this chapter, you’ll take build customizations to the next level by learning how to:
- Change build settings in a maintainable manner with build configuration files.
- Sign your app differently depending on the build configuration.
It’s time to take your first steps out of Xcode’s comfy UI when it comes to preparing your build pipeline. Xcode will still do the compilation for now, but you’ll prepare your build settings with configuration files instead of Xcode’s build settings editor.
Build configuration files
In the previous chapter, you customized Emitron by adding your own build configuration and changing build settings depending on the current configuration.
The app’s bundle identifier and icon change based on build configurations. However, are there any other settings that change between dev, alpha and release build? To find out, you’d need to scroll through over a hundred different build settings. And, check to see if they change based on configuration.
Scrolling through build settings is tedious work. Wouldn’t it be easier if you could store all the customized build settings together in one place? That way, you’d know exactly where to go to modify build settings for a particular release type.
This is where configuration files come in. A configuration file is a simple text file where you can keep build settings and their values. The contents of a configuration file look something like this:
PRODUCT_BUNDLE_IDENTIFIER = com.raywenderlich.emitron.pias SWIFT_VERSION = 5.0
On the left of the
=, you write the name of the build setting. On the right, you set the value. And that’s it! Configuration files are easy to read and easy to change.
By using different configuration files for different build configurations, you can keep all the changes to settings in one place. If you tend to forget about the changes you made six months ago, your future self will thank you. :]
Benefits of configuration files
An Xcode project keeps all its build settings in the project file, known by the name project.pbxproj. This file holds everything unique about the project, including every target, configuration and scheme.
Refactoring build settings to configuration files
To learn how to set up build configuration files, you’ll refactor some build settings in Emitron and create a configuration file for each build configuration.
Adding build settings
Currently, both the bundle identifier and app icon change depend on the build configuration. They’re buried within the project.pbxproj file, and now you’ll move them to your new configuration file.
PRODUCT_BUNDLE_IDENTIFIER = $(inherited).dev ASSETCATALOG_COMPILER_APPICON_NAME = $(inherited).dev PRODUCT_NAME = rwenderlich Dev
Applying configuration files
In the Project navigator, click on the Emitron project to reach the project screen. Make sure you’re on the project’s Info tab.
Resolving build settings
You set build setting values in your configuration file, but Xcode isn’t guaranteed to use those values at compilation. When Xcode needs to resolve the build setting, it chooses the most specific value it can find between the three different levels:
Resolving bundle identifier and app icon settings
The Product Name gets its value from Dev.xcconfig, but the app icon and bundle identifier don’t do the same.
Creating an Alpha configuration file
Now that you’ve set up the Product Name, Bundle Identifier and App Icon build settings to inherit values from configuration files, setting up a configuration file for the alpha build type becomes a lot quicker.
PRODUCT_BUNDLE_IDENTIFIER = $(inherited).alpha ASSETCATALOG_COMPILER_APPICON_NAME = $(inherited).alpha PRODUCT_NAME = rwenderlich (⍺)
Configuration file for the release build
So far, you’ve created two configuration files: Dev.xcconfig for the dev build and Alpha.xcconfig for the alpha build. That leaves the release build without a configuration file:
Code signing for different build types
Now that you have a shiny new alpha build, you also need a new provisioning profile for it. You need to do this because Emitron Alpha is a different app compared to the Emitron release build. In order to upload builds to App Store Connect, you can’t use the same provisioning profile for two different apps.
Signing the alpha build
Finally, take a look at the Alpha section.
- Build configuration files are a maintainable way to handle changes between builds.
- A setting in a configuration file can reference itself, with
$(inherited), or any other build setting.
- The chain of resolution determines the resolved value of a build setting, so always check to make sure that the values in a configuration file will resolve as expected.
- Code signing can change by your chosen build configuration.