Ten Years of BuildSettingExtractor
January 31, 2025
Ten years ago today I released the first version of BuildSettingExtractor.
For those not familiar, BuildSettingExtractor (BSE) is a free, open-source utility that provides a fast, easy way to extract build settings from an Xcode project into a set of xcconfig files.
(And even that description likely makes very little sense unless you develop software for Apple platforms.)
Reaching milestones like this make me reflect on the passage of time and think things like “How is it possibly ten years?”
So today I take a little walk down memory lane to celebrate the anniversary of BuildSettingExtractor.
Origin story
I was watching an NSScreencast episode by Ben Scheirman (friend and longtime guitarist in the Breakpoints) describing setting up xcconfig files.
(In fact, it was this little beauty released on January 29, 2015: Episode 154: xcconfig Files.)
Part of the episode demonstrated copying and pasting build settings out of Xcode into xcconfig files.
All of the copying and pasting made for a tedious process. In addition, at the time it also required a lot of manual clean up of the pasted values. (As of Xcode 16, pasted build settings are in valid xcconfig format.)
Months earlier I had been futzing around with some code I had written to extract build settings from an Xcode project but I had no intention of releasing it until I watched that episode.
It bothered me thinking about people going through a tedious, time-consuming, error-prone process, when I already had written some code that would do the same thing quickly and easily.
I cleaned up the existing code, added a user interface, and released BuildSettingExtractor 1.0 just a few days later on January 31, 2015 as an open source project.
A decade with the same simple interface. Drop an xcodeproj file on it—it spits out xcconfig files.
What does that setting do?
About ten days later the second release of BuildSettingExtractor quickly followed the first. This version added one of my favorite features: generating build setting info.
There are dozens upon dozens of build settings and it’s often not obvious how they behave. BuildSettingExtractor can annotate each setting with an explanatory comment gleaned from Xcode.
This info is available wherever you are looking at the xcconfig file—in GitHub, text editors, diff tools. No trip to a reference webpage or Xcode help is required to figure out what a build setting does.
For example:
// Enable Testability // // Enabling this setting will build the target with options appropriate for running // automated tests against its product. // // This setting can be enabled when building targets for debugging if their products will // be tested. This may result in tests running slower than otherwise. // // When this setting is enabled: // // * `GCC_SYMBOLS_PRIVATE_EXTERN` is disabled (`-fvisibility=hidden` will not be passed // to `clang`). // * `-enable-testing` is passed to the Swift compiler. // * `-export_dynamic` is passed to the linker. // * `STRIP_INSTALLED_PRODUCT` is disabled (`strip` will not be run on the produced // binary). ENABLE_TESTABILITY = YES // Build Active Architecture Only // // If enabled, only the active architecture is built. This setting will be ignored when // building with a run destination which does not define a specific architecture, such as // a 'Generic Device' run destination. ONLY_ACTIVE_ARCH = YES
BuildSettingExtractor generates automatically documented xconfig files.
For those who prefer a pithier xcconfig file, there is also a setting to turn these comments off.
Design goals
A decade ago, I set a few design goals which have guided each version of BuildSettingExtractor:
- Safe
- Focused
- Easily Maintained
The design goals were driven primarily by the following:
-
The Xcode project file is a proprietary, unpublished format. Although the format has been remarkably stable for many years, it is still subject to change without warning at any time.
-
Time is limited and always at a premium. The less time required to maintain a piece of software the more likely it can be maintained over a long period of time.
From the beginning, safety has been an explicit goal. A user should never have to worry that BuildSettingExtractor would leave them with a corrupted or incorrectly formatted project file.
For that reason, BSE never changes the original project file. Extracting the build settings is a read-only operation.
This means that BuildSettingExtractor will generate xcconfig files, but it is up to the user to set up their Xcode project to use the configuration files.
I periodically think about adding this functionality to BSE to automate the project setup.
And, every time, I come back to those initial design goals and decide against it.
Beautifully, Unapologetically Objective-C
The app began in Objective-C and has stayed that way.
The initial choice was because the core functionality was already in Objective-C and I was very familiar with the Obj-C AppKit APIs.
At the time Swift 1.0 had only been released for four months and I was trying to use what I already knew well to release the app quickly, as opposed to using the app as a way to learn Swift.
Looking back at the last ten years, developing in Swift and Objective-C have been two very different experiences.
Swift brings with it many great language features as well as a lot of excitement.
But one major benefit of choosing Objective-C has been stability.
If I had written BuildSettingExtractor in Swift a decade ago the code base would have needed to do major migrations to Swift 3, Swift 4, a minor one to Swift 5, and now to Swift 6.
Throughout that time, the Obj-C code has just kept working with a minimum of fuss.
I have considered migrating to Swift and SwiftUI, but as long as the tool continues to work as intended without requiring a great deal of maintenance, there are plenty of other things to spend time on.
And finally, maintaining BuildSettingExtractor keeps me from forgetting how to write Objective-C.
What’s next for BuildSettingExtractor?
The main thing that has been on my to-do list is adding Sparkle support for automatic updates from within the app.
Are there things you would like to see in BuildSettingExtractor? Feel free to file any requests using the project issue tracker.
And if you have yet to experience the glorious build setting extracting splendor that this utility provides, you can download it for free at buildsettingextractor.com.
As always, I hope you find it useful! •
If you’d like to step back in time you can read the initial announcement…
…and another post introducing build setting info comments.
Categories: Software Development, iOS, macOS, tvOS, visionOS, watchOS