Well, it's about customizing the build process in general. There are various use cases for this. For instance encryption keys which should not be part of source files, or automatically adjusting relative framework pathes (e.g. due to differences in teams). Another very typical use case is dynamically filling Info.plist fields by Xcode scripts.
So let's just stick with the latter use case: Say you wanted to automatically compile an Xcode project using always latest git HEAD commit's SHA1 as user visible build number for the generated app binary. If there was a way to let a "Run Script" build phase script adjust Xcode's environment, then all you had to do was adding a tiny script like this to the Xcode project "Run Script" build phase:
FOO_GIT_REV=`(cd $SRCROOT && git rev-parse --short=4 --verify HEAD)`
export FOO_GIT_REV
And in the Xcode target's Info.plist you would simply use that environment variable like:
<key>CFBundleVersion</key>
<string>$(FOO_GIT_REV)</string>
and that's it.
Of course there are workarounds for this example. Typically people use something like this instead in an Xcode "Run Script" build phase script:
system("/usr/libexec/PlistBuddy -c \"Set :CFBundleVersion ${FOO_GIT_REV}\" \"${INFOPLIST_FILE}\"");
So you extract the git commit hash and write it literally to the Info.plist file instead within the same Xcode script. But the problem with this approach is that the script is constantly modifying Info.plist itself of course, so you are mixing a file being under version control (Info.plist) with dynamically generated content by a build script. Hence you always have that Info.plist on your dirty list e.g. with "git status" and you cannot git ignore it, since the rest of the Info.plist file is still relevant for version control of course.
If there was some way to manipulate Xcode's environment variables by script, that would convey many build configuration tasks in an easy and convenient way. Because you can actually reference environment variables almost everywhere in Xcode already.
