BuildSettingExtractor moves Xcode build settings into xcconfig files

A one time migration, not a configuration manager

BuildSettingExtractor is a utility that extracts build configuration settings from an Xcode project into a set of xcconfig files. The project documentation is direct about its purpose: if you decide to move Xcode build settings out of your project file and into xcconfig files, this utility can make that initial move easier.

It is also, in the documentation's words, an easy way for the curious to take a look at the build settings in a project without the fear of accidentally changing them. That second use is underrated. An inherited project with dozens of targets and layered settings is genuinely hard to read, and generating the effective values as plain text files makes the whole configuration visible in a directory listing.

The unit of output is precise. For each target and for the project itself, the app generates one xcconfig file per build configuration, plus a shared xcconfig file containing all the shared build settings for that target. So a project with two targets and Debug and Release configurations produces a predictable set of files rather than a merged blob.

The audience is an Xcode user who has hit the point where the project file has become the place where configuration lives, and wants that inverted so the settings are reviewable as text and can be diffed, shared and version controlled like code.

The primary language of the repository is Objective-C, and the project is built as a native Mac app with an Xcode project of its own.

Three steps and a Preferences window

The interaction is short, which is part of why the tool is usable. The documentation lists the whole flow.

1. Launch BuildSettingExtractor 2. Drag an Xcode Project file, an xcodeproj, to the app window 3. Choose a destination folder

Generation options are set from the Preferences window, opened with Command and comma from the BuildSettingExtractor menu. The Preferences panes have previews, so you can see the effect of an option, for example the line spacing between settings, before you commit to a run.

The drag and drop is the central interaction, and it was added deliberately. Version 1.4.1 added the ability to drag an Xcode project to the app icon to extract settings, which is the fastest path when you want to look at a project you did not create. The file is opened read only, and the output goes wherever you point it.

The current release is distributed pre-built, code-signed and notarized, and the download is at buildsettingextractor.com. The notarization and signing matter more than they might appear. A utility that reads your Xcode project and writes files next to it is exactly the kind of binary a cautious developer will refuse to run unsigned, and the sandboxing added in version 1.3.2, with an entitlement for read and write access to user selected files, is the same argument answered on the code side.

The repository also holds the source, with the app, its tests, a Config directory and CI scripts, so building it yourself is a normal Xcode exercise rather than an unsupported path.

The generated files carry Xcode's own explanations

The nicest thing about the output is that the build setting descriptions come from Xcode itself, and are written into the file as comments above the setting they describe.

A generated file looks roughly like this.

// 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)

A second setting follows with its own description block, for example the project-relative path to the Info.plist file used by bundles.

The comments come from build setting info files that ship with Xcode and are updated for each Xcode release, which is why the version history mentions updating the list of build setting info files for Xcode 13.3, 15.0, 15.3 and others. There is also a mechanism, added in 1.4.1, for handling build setting info files that are introduced in a new Xcode version.

If you want a compact file instead, the comments can be turned off in the Preferences window, which leaves just the settings.

FRAMEWORK_SEARCH_PATHS = $(DEVELOPER_FRAMEWORKS_DIR) $(inherited)
INFOPLIST_FILE = BuildSettingExtractorTests/BuildSettingExtractorTests-Info.plist

Note the `$(inherited)` in the value. The extraction preserves the inheritance marker, which is what makes the resulting xcconfig files safe to base a project on, since a value that is not inherited would stop picking up changes made higher up in the configuration.

Three things it deliberately will not do

The notes section of the documentation is short, and each line is a boundary. It is worth reading it as a list of what the tool refuses to do.

BuildSettingExtractor does not alter the original Xcode project file. The extraction is read only on the input side, so the project you point it at is unchanged, and the only effect is the files it writes into the folder you chose.

It does not update existing xcconfig files. It does a one-time extraction. This is the limitation with the most practical consequence, because a project that adopts xcconfig files will keep changing its settings afterwards, and nothing here will keep the generated files in step with those changes. The tool is for the migration moment, not for the life of the project.

It does not hoist shared target build settings to the project level. A setting that is defined identically across every target of a project stays where it was, in the per-target files, rather than being moved up into a project-level xcconfig where it would apply to all of them. That is a conservative choice, since hoisting changes the semantics of the configuration rather than just its representation, and it is also the kind of judgement call that is safer left to a human who knows the project.

And then there is the fourth line, which is a joke and also an accurate summary of the tone of the project: do not taunt BuildSettingExtractor.

Xcode compatibility is tracked release by release

The version history is the clearest signal about how this project is maintained, and it is a list of Xcode versions.

Version 1.4.8, dated 23 December 2024, updated the app to extract build settings from Xcode 15.3 compatible project files and from Xcode 16.0 compatible project files, added a new line at the end of generated files, and was tested on macOS 15.1.1 Sequoia on Apple Silicon, built with Xcode 16.2.

Version 1.4.7, from March 2024, updated the list of build setting info files for Xcode 15.3. Version 1.4.6, from June 2023, moved to Xcode 15.0 compatible project files. Version 1.4.5 added grouping to conditional build setting generation and updated the URL written into generated files.

Two entries go back further. Version 1.4 added the preferences for generating xcconfig files in folders grouped by target, for grouping the project xcconfig files separately, for setting the name of the enclosing folder, for saving the generated files next to the source project, and for the line spacing and value alignment in the output. Version 1.4.2 added native Apple Silicon support.

The maintenance pattern is now clear. Each Xcode release brings a new project file format, and the utility has to be updated to read it. The repository is not archived and the last push was on 2026-09-29, so work is still happening, but the newest tagged release is 1.4.8 from December 2024, and it supports project files up to Xcode 16.0. If you are on a newer Xcode, that gap is the first thing to check.

Where a one-time extraction is the wrong tool

The limitation worth naming is the gap between the moment of migration and the life of the project. BuildSettingExtractor produces a snapshot of the settings as they were when it ran. After that, the xcconfig files and the Xcode project are two sources of truth unless you delete the settings from the project, and the tool has no mechanism to reconcile them.

That means the workflow it supports is: run the extraction, review the output, then point the project at the generated files and remove the duplicated values from the project file. The second half is manual, and it is where the risk lives, because a setting that is copied rather than moved will be edited in the wrong place later.

There is a second scenario where it is the wrong tool. If a project already keeps its settings in xcconfig files, this app has nothing to do. And if the goal is to compare two configurations or to see what a build setting actually resolves to across layers, a different kind of tool is the right one, because this one reads the project file rather than asking the build system to evaluate it.

The alternative approach, for what it is worth, is to keep the settings in the project and use the generated output purely as a reference. The extraction is still useful there, because the comments and the resolved values make an opaque configuration readable, and a diff between two extractions taken a month apart shows what changed in the project. What the app cannot do is keep the two in sync, and it says so plainly in the notes rather than pretending otherwise.

Editorial conclusion

BuildSettingExtractor suits an iOS team that has decided to move build settings out of a large Xcode project into xcconfig files and wants the first pass done mechanically, or a developer who simply wants to read a project's effective settings without touching them. It is the wrong tool for a project whose settings are already in xcconfig files, and for keeping configuration in sync over time, since the extraction is one time only. Check first the version history for the Xcode release you run, because the utility has to be updated to read each new project format, and note that shared target settings are not hoisted to the project level.

Frequently asked questions

Official sources

1. dempseyatgithub/BuildSettingExtractor on GitHub
2. Issues
3. README
4. Releases