Why build configs are so cool

Build configurations are at the heart of Xcode's organizational apparatus. All of those hundreds of files that make up a project would be nothing without a clever set of files somewhere that know how to stitch it all together. But of course, we say building, rather than stitching. Stitch configurations sounded pretty good to me, but never caught on.

There are many changes that may be desirable according to the circumstances for which an app is being compiled. In this chapter, we're going to imagine the client has asked for two different versions of an app; one might be used to access a staging server to obtain dynamic data, while the other would use the client's actual production server (the one that nobody is going to want to perform experiments on because it's being used by a million users a day).

These two versions will need to reside side by side on a single machine, so they will also need different bundle IDs.

Build configurations allow us to make adjustments both within the code itself, and in the app's build settings and Info.plist file, and this is just what we need for the scenario described above--a scenario that is almost universal when building enterprise apps.

These are by no means the only uses of build configurations, but it's an excellent place to start.

The steps we will follow, very broadly, are as follows:

1. Create a new build configuration.
2. Set one of our schemes to use it.
3. Create custom User-Defined Build Settings.
4. Set some of the Info.plist properties to reference those user-defined build settings.

1. Make some of the app's build settings dependent on which build configuration is being used.
2. Use those settings in our code.