New Xcode Build System and BuildSettingExtractor

Last week at WWDC 2017, Apple announced a new build system for Xcode, with an opt-in preview in Xcode 9. The new system is written in Swift and promises to be a significant advance in a number of areas including performance and dependency management. The new system is built on top of the open source llbuild project and lays the foundation for integrating the Xcode build system with the Swift Package Manager.

You opt in to the new build system per project or workspace. To do so in the Xcode 9 beta, open a project file and then go to File > Project Settings… and in the sheet that appears, choose New Build System (Preview) from the Build System popup menu. Note that the menu item will be File > Workspace Settings… if you are working with a workspace.

Project settings sheet with popup menu to select build system

Opt-in to the new build system for a project in File > Project Settings…
(For a workspace use File > Workspace Settings…)

The big news of a new build system made me curious to see if there were any changes I would need to make to BuildSettingExtractor.

Icon for the app BuildSettingExtractor

BuildSettingExtractor helps you move to xcconfig files.

If you are not familiar with it, BuildSettingExtractor is an open source utility that helps you move to using xcconfig files. It reads the build settings embedded in an Xcode project file and extracts the settings into xcconfig files. It can also extract the Xcode help for each build setting to produce automatically documented configuration files. (Read my prior post Generating Xcode Build Configuration Files with BuildSettingExtractor for more about the benefits of using xcconfig files.)

My investigation led me to look more closely at what was changing and what was staying the same when it came to the new build system and build settings in Xcode 9.

When it comes to build settings, there are two big operations: Defining build settings and using build settings.

As developers, we spend our time on the first part, defining build settings1. In a complex project or workspace, this can be an involved process. Defining build settings includes all of the following:

  • Build settings defined for each target and for the project itself
  • Variable substitution to define derived build settings using ${} or $()
  • Conditional build settings based on build configuration, architecture, and SDK
  • Optionally using xcconfig files to define build settings
  • Understanding the well-defined hierarchy of how build settings are inherited and used

In the end, these intricate and flexible mechanisms for defining build settings resolve into a big dictionary of key-value pairs that is passed to the build system.

The build system is what uses the build settings to help direct how it builds a target. The build system coordinates the various tools required, such as the compiler and linker. It uses a target’s build phases and build settings to generate a build product (e.g. app, extension, framework, library). It understands all of a target’s dependencies and builds them as well. The build system is a complicated beastie with a lot of responsibilities and it is what is being modernized beginning in Xcode 9.

Logo of new Xcode build system

New build system.
Same build settings.

On a number of my projects, I’ve switched from the current build system to the new build system in Xcode 9 to investigate. It appears that everything about defining build settings remains unchanged. Moving between the old and new build systems did not cause any build setting changes or recommended changes. The mechanisms for generating that giant bucket of key-value pairs known as build settings seem to be just the same as before.

This is great news. As developers, we don’t need to learn a new complex system for defining build settings. We get to enjoy the benefits of a new, faster, modern build system with our existing build settings left intact.

As the developer of BuildSettingExtractor, this is also great news—no big changes required. After doing some testing and a tweak here and there, BuildSettingExtractor is now updated to work with the Xcode 9 beta. I invite you to check out BuildSettingExtractor and the new build system in Xcode 9. •


1And debugging them.

Learning More About Xcode Build Settings with BuildSettingExtractor

Last week I posted about BuildSettingExtractor, a utility that makes it easy to pull the build settings out of an Xcode project file and into xcconfig build configuration files. (The post also mentions some xcconfig file benefits with links to ‘how to’ information. Read the earlier post here.)

I also wanted BuildSettingExtractor to be useful for anyone who wants to learn more about the build settings in their projects. To that end, the latest version, available on github, generates build setting descriptions gleaned from the installed version of Xcode.

For example:

// Framework Search Paths
// 
// This is a list of paths to folders containing frameworks to be
// searched by the compiler for both included or imported header
// files when compiling C, Objective-C, C++, or Objective-C++, and by
// the linker for frameworks used by the product. Paths are delimited
// by whitespace, so any paths with spaces in them need to be
// properly quoted. [-F]

FRAMEWORK_SEARCH_PATHS = $(DEVELOPER_FRAMEWORKS_DIR) $(inherited)
	

// Info.plist File
// 
// This is the project-relative path to the plist file that contains
// the Info.plist information used by bundles.

INFOPLIST_FILE = BuildSettingExtractorTests/BuildSettingExtractorTests-Info.plist

Inline Build Setting Info

To learn more about build settings, Apple provides the Build Setting Reference (Apple developer documentation links are notoriously fragile, just search for the document) as well as Quick Help in Xcode when a build setting is selected. (In Xcode choose View > Utilities > Show Quick Help Inspector (Cmd-Opt-2))

In addition to these ways of learning more, BuildSettingExtractor gleans the build setting info from Xcode and puts it inline in the generated xcconfig files. This has a few benefits:

  • Read about each build setting without selecting setting one by one in Xcode
  • Read about only the build settings currently set in your project and targets
  • Information about build settings is available wherever you are looking at the xcconfig file: github, text editors, diff tools, etc.

What if I don’t want this lovely but verbose feature?

If you want BuildSettingExtractor to generate pithy xcconfig files without the build setting info, Choose BuildSettingExtractor > Preferences… (Command-,) for the new preferences sheet and turn it off.

BuildSettingExtractor Preferences Sheet

Happy Building! (and a call for help)

I hope you find BuildSettingExtractor useful, either as a learning tool, or to get rolling with xcconfig files. If you do find it useful, please spread the word about it: https://github.com/dempseyatgithub/BuildSettingExtractor.

As for the call for help, if you would like to help out with a basic app icon for BuildSettingExtractor, the utility can emerge from the primordial world of the generic app icon. Contact me if you are interested. •

Generating Xcode Build Configuration Files with BuildSettingExtractor (xcodeproj → xcconfig)

The most recent NSScreencast covered using build configuration files to specify build settings in Xcode. (Episode #154)

Using build configuration files—or xcconfig files as they are known—has some definite benefits.  However, as seen in the screencast, the initial process of copying the current build settings out of an Xcode project into xcconfig files is tedious and potentially error-prone.

Screenshot of Build Setting Extractor 1.0

Nuthin’ fancy. Drop an xcodeproj file on it—it spits out xcconfig files.

To aid in that initial extraction process, I wrote a utility app called BuildSettingExtractor.  It is available on github at https://github.com/dempseyatgithub/BuildSettingExtractor.

The app is a simple droplet utility: drop an xcodeproj file on it, choose a destination folder, BuildSettingExtractor will extract the build settings from the project and generate xcconfig files.

A set of files is generated for each target in the project and for the project itself.  Each set of files includes one xcconfig file per build configuration and one xcconfig file of shared settings. For example, a typical Xcode project will generate nine xcconfig files: three sets of files for the app target, test target, and project with three files for Debug, Release and Shared in each set.

I hope you find BuildSettingExtractor useful. Even if you are just curious about project build settings, this is an easy way to inspect a project’s build settings without fear of accidentally changing them.

A little more about xcconfig files

By default, Xcode stores all build configuration settings in the project file itself. However, you can tell Xcode to base a build configuration’s settings on a build configuration file instead.

A build configuration file is a text file of key-value pairs. An xcconfig file can also contain comments and include other xcconfig files.

//
// Project-Debug.xcconfig
//

#include "Project-Shared.xcconfig” // Include other xcconfig files

// An xcconfig file is a text file of key-value pairs.
// Use comments to record why you are using certain build values.
// The /*comment*/ and #comment styles are not valid in an xcconfig file.

COPY_PHASE_STRIP = NO
GCC_DYNAMIC_NO_PIC = NO
GCC_OPTIMIZATION_LEVEL = 0
GCC_PREPROCESSOR_DEFINITIONS = DEBUG=1 $(inherited)
GCC_SYMBOLS_PRIVATE_EXTERN = NO
MTL_ENABLE_DEBUG_INFO = YES
ONLY_ACTIVE_ARCH = YES

There are some benefits to using xcconfig files:

  • Build settings are not in project file—this removes one source of project file merge conflicts
  • Build settings can be documented using comments
  • An xcconfig file of shared settings can be included in each build configuration

There are also potential drawbacks to using xcconfig files.  One potential pitfall is that the build settings for a configuration are based on the xcconfig file—but settings set in Xcode override the xcconfig file settings. This can leave you with unexpected build behavior because an errant build setting set in Xcode is overriding the xcconfig file setting.

This issue is compounded by the fact that when new Xcode versions update project settings, the settings are added to the project, not to an xcconfig file.  So when using xcconfig files, some vigilance is required to keep an eye out for build settings being added to the project.  These stray build settings should be moved from the project to the appropriate xcconfig file.

What Next?

BuildSettingExtractor generates xcconfig files from a project—it does not set your project up to use them.  Here are few resources that walk through that process:

I was inspired to release BuildSettingExtractor by Episode #154 of NSScreencast. The episode is a step by step demo walking through the process.

By the way, if you aren’t familiar with NSScreencast, I recommend taking a look. Ben Scheirman (@subdigital) presents weekly bite-sized screencasts covering a wide range of development topics. Some screencasts are free and some, like Episode #154, require a subscription. (Ben also plays guitar with James Dempsey and the Breakpoints, but that has yet to be the subject of a screencast.)

The blog post Using xcconfig Files For Your Xcode Project by Jont Olof Lyttkens (@jontolof) explains how to set up a project to use xcconfig files in Xcode 6.

Finally, Building the Build System by Rob Napier (@cocoaphony) is an older post, written for an older version of Xcode, but the overall concepts and explanation of the benefits are still relevant.

In each of these walkthroughs, instead making a bunch of xcconfig files by hand and then copying and pasting from the project into the correct file, you would use BuildSettingExtractor instead. •

A Brief Visual History of Apple Home Page Tabs

This week brought announcements of new iPhones, Apple Pay, and Apple Watch, as well as the quiet departure of the iPod classic, the last remaining click-wheel product in the iPod lineup.  It also brought something that happens much less often than new product announcements—changes to the look and lineup of tabs at the top of the page at apple.com.

We can see a few different things by looking at how these have changed over the last fourteen years.

Apple Home Page Tab History

Click for the full-sized image

First, we see how the user interface has evolved.  The tabs begin with the natty pinstripes and bubblicious tabs of the original Aqua interface, appearing on the home page immediately after Aqua was introduced in January 2000.  This was the first production use of Aqua elements by Apple—the release of Mac OS X, 10.0 was over a year away.  Through the next fourteen years, we see the designs become simpler as the candy look becomes more subtle before disappearing entirely.  With the removal of dividing lines between items, the original tabs have finally morphed into a simple menu bar.

This week’s update also ended the reign of Lucida Grande as the font of choice—the honor now belongs to the Apple variant of Myriad.

The content of the tabs shows an interesting progression as well.  The Apple logo, Store, and Support tabs are a common thread throughout with Search appearing surprisingly late in the game in 2007.  These unchanging outer items are like bookends around the changing world of Apple over time.

For the first seven years, the inner tabs mainly focused on software (QuickTime, Mac OS X, iTunes) and different incarnations of online services (iReview, iCards, iTools which became .Mac).  The first hardware to appear on a tab was iPod, but it had to share a tab with iTunes for almost seven years before getting a tab of its own.

With the release of the iPhone in 2007, the tabs became more hardware-centric, with Mac and iPhone getting their own tabs.  With the introduction of the iPad in early 2010, the center of the tabs became all hardware lines, with the exception of iTunes (both software and a service).

And, of course, this week Watch joins the lineup. It seems a little odd not to use the full product name Apple Watch or <Apple logo>Watch, especially since Watch is both a noun and a verb.

Although the appearance and focus of the tabs have changed over time, it is interesting to note that almost all tabs name something that has been an enduring part of the Apple ecosystem (the exceptions being iReview, iCards, and the Switch campaign).  Details may have changed—iTools begat .Mac begat MobileMe begat iCloud, Mac OS X is now OS X—but there are some very consistent through lines.  Here’s hoping the Apple Watch is one of those through lines for a long time to come.•

I used the Internet Wayback Machine to help track these changes down. If I’ve missed any changes, please feel free to let me know!

Is the end near for System Preferences?

Table comparing settings / preferences on Apple platforms

One of these things seems out of place. Can you spot it?

When Mountain Lion was announced back in February, I enjoyed reading John Gruber’s Daring Fireball account of his advance peek of the upcoming OS, including this section:

“Apps have been renamed for cross-OS consistency. iChat is now Messages; iCal is now Calendar; Address Book is now Contacts. Missing apps have been added: Reminders and Notes look like Mac versions of their iOS counterparts. Now that these apps exist for the Mac, to-dos have been removed from Calendar and notes have been removed from Mail, leaving Calendar to simply handle calendaring and Mail to handle email.”

While I don’t believe that the Mac should become an iOS clone, I do think that natural similarities between the platforms should be emphasized.

This made me wonder about the fate of System Preferences. Continue reading