Validate Project Settings: Never
Xcode likes to “helpfully” suggest changes to your project’s build settings. And this doesn’t happen just once. New versions of Xcode come up with even more “helpful” suggestions. So, get used to seeing the warning icon when you open your project. I mean projects. My company’s main source repository contains almost 90 Xcode projects. Each of which will show a warning icon when you open it with a new version of Xcode.
[…]
My genius idea, if I may say so myself, thank you, was to manually edit the project file and replace the
LastUpgradeCheckvalue with9999.Unfortunately, this was not a complete solution. I discovered that Xcode checks not only the project but also the schemes. So you also have to manually edit the
.xcschemefiles for your project(s). The relevant key in those files isLastUpgradeVersion, which can also be set to9999.
The problem is a well-managed project might include settings that match Apple’s recommendations but rather than being set explicitly on a project or target node, are instead inherited from a project or target base .xcconfig file. In this scenario, Xcode repeatedly nags about updating the project or target even though the desired setting already shines through.
The problem with allowing Xcode to simply set the desired settings on the project or target is it shuts down the ability to accurately control build settings from the centralized location in the .xcconfig file.
Indeed, I’ve found Xcode’s suggestions to be more hindrance than help. They’ve broken my projects by overwriting settings with incorrect values and also, like Jalkut says, messed up inheritance, which led to problems later. But I do like to see what Xcode is suggesting, and, unlike Johnson, I don’t have very many projects. So these days I let Xcode change what it wants to and then (usually) Git-revert all the changed lines in the project file except for the LastUpgradeCheck.
Update (2015-05-14): Daniel Jalkut:
I also added a test for unwanted build settings to my integration tests, and am thinking of adding a commit hook to reject them.
I made an effort to codify settings by whether they should or shouldn’t, or “not sure.”
4 Comments RSS · Twitter
Can't you just uncheck the changes you don't want, and press 'Apply'? Then Xcode won't apply the changes you unselected you and won't nag you again (until the next time). I think that is what I do most of the time.
Ah, good one. In this case, I suppose it can be problematic when there are more than a handful of changes, then trying to reverse-engineer the changes in the project xml. Has this been an issue sometimes? Is the xml diff self-explanatory in most cases?
