Xcode Build Configuration Files

Tram Ho

Software development best practices provide for a strict separation of configuration from code. However, developers on Apple’s platforms often struggle to address these principles with Xcode’s multi-project workflow.

Understanding what each project setting does and how they all interact is a skill that can take years to hone. And the fact that much of this information is buried deep in the Xcode’s GUI makes us disapprove.

Navigate to the project editor’s “Build Settings” tab and you’ll be greeted by hundreds of build settings spanning project, target, and configuration classes – and that’s nothing to say about tabs rest!

Luckily, there is a better way to manage all this configuration without involving clicking through a maze of revealing tabs and arrows.

This week, we will show you how you can use text-based xcconfig file to externalize build settings from Xcode to make your projects more compact, easy to understand, and powerful.

Check out XcodeBuildSettings.com for a complete reference of all supported build settings for the latest version of Xcode.

Xcode build configuration files :, more commonly known by the xcconfig file extension, allows the build settings for your application to be declared and managed without Xcode. They are plain text, which means they are much more user-friendly to the source control system and can be modified using any editor.

Basically, each configuration file consists of a sequence of key-value assignments with the following syntax:

For example, to specify a Swift language version for a project, you must specify the SWIFT_VERSION build setting as follows:

At first glance, the xcconfig files look like .env files, with simple syntax, separated by new lines. But there’s more to building Xcode configuration files than eye catching. Witness!

Retains existing values

To concatenate instead of replacing existing definitions, use the variable $ (inherited) like so:

You usually do this to generate a list of values, such as paths in which the compiler searches the frameworks for included header files (FRAMEWORK_SEARCH_PATHS):

Xcode specifies inheritance values ​​in the following order (from lowest priority to highest priority):

  • Platform Defaults
  • Xcode Project xcconfig File
  • Xcode Project File Build Settings
  • Target xcconfig File
  • Target Build Settings

Reference value

You can replace values ​​from other settings with their declared names with the following syntax:

Alternatives can be used to define new variables according to existing values ​​or inline to dynamically construct new values.

Set the fallback values ​​for the referenced build settings

In Xcode 11.4 and later, you can use the default evaluation operator to specify the fallback to use if the referenced build setting evaluates to empty.

Condition installs

You can conditionally install builds under their SDK (sdk), architecture (arch), and / or configure (config) according to the following syntax:

Given a choice between multiple definitions of the same build setting, the compiler will deal with specificity.

For example, you can specify the following build settings to speed up local builds by compiling only for the working architecture:

Includes build installation from other configuration files

The build configuration file can include settings from other configuration files using the #include syntax like the equivalent C command on which this functionality is based:

As we’ll see later in the article, you can take advantage of this to create cascading lists of build settings in really powerful ways.

Create a build configuration file

To create a build configuration file, select the menu item File> New File… ”(⌘n), scroll down to the section labeled“ Other ”and select the Configuration Settings File template. Next, save it somewhere in your project directory, making sure to add it to your desired goal

Once you’ve created the xcconfig file, you can assign it to one or more build configurations for the associated goals.

Now that we’ve covered the basics of using Xcode build configuration files, let’s look at some examples of how you can use them to manage development, stage, and development environments. manufacturing.

Customizable app names and icons for internal works

IOS app development typically involves a mix of various internal builds on your emulator and test device (as well as the latest version from the App Store, for use as a reference). .

You can make things easier yourself with xcconfig files assigning each profile a unique name and application icon.

Managing the constants on different media

If your backend developers compile themselves according to the aforementioned 12 Factor App philosophy, they will have separate endpoints for development, stage, and production environments.

On iOS, perhaps the most common approach to managing these environments is to use conditional compile statements with a build setting like DEBUG.

This should get the job done, but cause a code / configuration parse error.

An alternative approach takes these environment-specific values ​​and places them where they belong – into xcconfig files.

To get these values ​​programmatically, however, we’ll need to take an extra step:

Access Install Builds from Swift

The build settings are determined by the Xcode project file, the xcconfig file, and the environment variables, available only at build time. When you run the compiled application, no surrounding context is available.

But wait a minute – do you remember seeing some of those build settings before in one of the other tabs?

When it happens, that info tab is really just a fancy presentation of the target’s Info.plist file. At build time, that Info.plist file is compiled according to the provided build settings and copied into the resulting application package. Therefore, by adding references to $ (API_BASE_URL), you can access the values ​​for those settings through the Foundation’s Bundle API’s infoDictionary property.

Following this approach, we can do the following:

When viewed from the call site, we found that this approach blended well with our best practices – no hard coded constants exist!

Xcode projects are monolithic, fragile, and opaque.

Luckily, xcconfig files go a long way to addressing these pain points. Moving configuration out of Xcode and into xcconfig files offers a wealth of benefits and provides a way to separate your project from Xcode details without leaving the Cupertino-approved “path of happiness” .

Link: https://nshipster.com/xcconfig/

Share the news now

Source : Viblo