This was done using search and replace. Presumably it should be done in Xcode so that it can adjust the xib for the new deployment target, otherwise what is the point of storing deployment version in the xib and provide it as a command line argument to the xib compiler as well (only to get a warning if the versions do not match)?
Since we have multiple application targets, it doesn’t make sense with a global APP_NAME variable.
Though if building the frameworks as standalone bundles and embedding them in different applications, we may need some sort of unique component in the bundle identifier, but we currently do not do this (they are all statically linked, so the Info.plist is currently unused).
Although this is actually deprecated in 10.10, new APIs are available in 10.9 and it will make addressing deprecation warnings when upgrading to 10.10 easier.
Some targets were including headers from frameworks not specified in their link dependencies. For a clean build this could cause an issue because the header was not available at the time of building the target.
The updated link dependencies are also based on what a target’s tests require. Ideally tests would have separate link dependencies, but as we don’t want to maintain this manually, this will have to wait until the build system automatically handles link dependencies.
Currently the commit command uses constants from the CommitWindow framework but should actually not be linked with it. However, the optimizer will strip dead code, so it should not result in much if any difference in the resulting binary and does solve a build dependency issue.
This was done in an attempt to prevent the warning saying “This file is set to build for a version older than the project deployment target.”
Unfortunately saving all the xibs did not get rid of the warning, even though tehy are all set to have 10.7 as their build target.
The latest xib format does however remove about 10.000 lines of XML.
I mainly dislike the trailing zeroes because CGFloat used to be a float but 1.0 is a double (1.0f would be a float). So better to under-specify and let the compiler figure out the proper type.
The ‘lastVersionDownloaded’ property used ‘assign’ (since it used to be an integer) which meant TextMate would likely crash when the property was read (and had a non-nil value), which it would, when TextMate did a version check after already having downloaded an update (but not yet installed and relaunched).
Also drop the atomic requirement of the ‘archive’ property since we no longer access it from multiple threads.
