Chapters
Chapters

Chapters

Hide chapters

iOS App Distribution & Best Practices

First Edition · iOS 14.4 · Swift 5.3 · Xcode 12.4

Before You Begin

Section 0: 6 chapters
Show chapters Hide chapters

Section I: iOS App Distribution & Best Practices

Section 1: 17 chapters
Show chapters Hide chapters

Section II: Appendices

Section 2: 2 chapters
Show chapters Hide chapters

10. Advanced Build Configurations
Written by Pietro Rea & Keegan Rush

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

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.3

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.

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.

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.

Key points

  • 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.
9. Build Customizations
11. Managing Secrets
Have a technical question? Want to report a bug? You can ask questions and report bugs to the book authors in our official book forum here.
© 2026 Kodeco Inc.

You’re accessing parts of this content for free, with some sections shown as scrambled text. Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now