I wrote almost ten years ago about a trick I use in my Xcode projects that lets me set the marketing version for my products in one place, a build setting, and then reference that build setting everywhere else the version number needs to be expressed. This is a cool trick that has saved me a bunch of dumb hand-editing over the years.
And yet, all these years I have been laboriously, and usually behind schedule, updating my source bases every year to advance the range of years that my copyright statement applies to. For example, here is the string for MarsEdit’s NSHumanReadableCopyright string:
MarsEdit ${APPLICATION_VERSION}, ©2003-2015 Red Sweater Software
You can see my use there of the aforementioned marketing version build setting. With the opportunity staring me in the face, why have I spent the past decade manually advancing the year from 2005 to 2006 to 2007 to … well, I guess the charitable explanation would be that I’ve had better things to do, but that particular tedium also ends today.
My projects make heavy use of Xcode configuration files, such that every application or framework target inherits consistent default build settings that reflect my opinions about which warnings should be enabled, what platforms to support, etc. My configuration files all take advantage of a kind of cascade of imported files such that ultimately, every target in every Xcode project in my source base inherits settings from a file called RS-Target-All.xcconfig, and every project likewise inherits settings from RS-Project-All.xccconfig.
Today I added a simple line to RS-Project-All.xcconfig:
CURRENT_YEAR = 2015
The result is that every project and target in my source base now has access to this custom build setting, thus I can change the contents of all my NSHumanReadableCopyright strings to e.g.:
MarsEdit ${APPLICATION_VERSION}, ©2003-${CURRENT_YEAR} Red Sweater Software
And I will never have to update the marketing string’s copyright year again, on any of my projects, for as many years as I keep updating and releasing new versions of them. Quite appropriately, the terminating year on the copyright span will always be the year when I built and shipped the app. All I have to do every January is edit the solitary Xcode configuration file.
Technically I could go a step further and incorporate the product name as a variable as well:
${PRODUCT_NAME} ${APPLICATION_VERSION}, ©2003-${CURRENT_YEAR} Red Sweater Software
But since the product name isn’t changing all the time, that just starts to feel a bit fussy.
Some people also take advantage of the Xcode option to preprocess the Info.plist file, which could potentially allow for even more fancy substitutions. Maybe you could use the C preprocessor’s built-in __DATE__ variable to extract just the current year somehow? I never turned on preprocessing of Info.plist files because, at least when I last considered it, there seemed to be some bugs with it.
For now, I’m satisfied by the little bits of time that defining this once will save me, not to mention the avoidance of inevitable errors I would make when editing each occurrence by hand.