You start off with a version number on you app’s splash screen. Then later you have an in-app profile screen the version number should be on. Then you realize your logging would be more useful if it had a logged the version info when the app started up. Now you need something to keep these versions all in sync and to easily update them.
When next year rolls around, you realized two releases into the new year that you’ve still not updated your copyright message with the current year.
I created a auto versioning script for Xcode for use in iOS and OS X projects to solve this. It’s available on gitlab and is called AutoVersionXcode. It uses the versioning you put in your General tab in Xcode to drive versioning across your app.
This script generates a version.swift (or version.h file if you’re using Objective C) with several different formats of your app version (with varying detail). It also makes other constants with your app name, configuration, copyright, and Xcode & SDK information. All this has been useful in either identifying or debugging apps in the past. You can use these contants in your code internally, in logging, or for user display on screens.
The README at the repository above has the install instructions.
Install & Use
You install this as a script phase early in your Xcode build process. Then each time you build your app the script will run (it’s fast) and build a new version.swift file.
You include that version.swift file in your app and use those global strings where you need that information. However, add “version.swift” to your .gitignore file as it’s rebuilt automatically.
This file has several ways of showing your app’s version information like:
let FullVersion = “1.0.0b1–2-F3380-dirty”
let Version = “1.0.0b1”
let SimpleVersion = “1.0.0”
let buildNumber = 1
This lets you use what you need and know that it’s updated correctly.
There is also application information like the app name, bundle ID, and configuration (debug or release typically). There’s also information about the Xcode environment and version used to build the app. Ideal information for logging during debugging and for release support too!
And there’s copyright. To make the copyright work the script needs a little help. You have to add the user-define settings in your target’s build settings: COPYRIGHT_NAME and COPYRIGHT_YEAR.
Near the top of the script there’s a place where you can enable CopyrightUpdating. If that’s on, then the COPYRIGHT_YEAR will be your first year and the current year will be the second year of the copyright. The name is used as well as in this example with “Acme Inc.” for the name and “2016” for the year:
“Copyright 2016–2019 by Acme Inc. All rights reserved.”
This script is setup to use a versioning system like semver with three digits. Also, it can handle either d, a, b, and f and a number after that like “1.2.3d3” which means version “1.2.3, development #3”. The other letters are for “alpha” or “beta” or “final” release. (You might use final in a complex project for final pre-public release testing).
Each version can have multiple build numbers. I’ve too have been stuck fixing build problems and having to index versions due to a limited build system!
The versioning can also include the git commit hash. After all, if you have that you know exactly what files and source code went into that build.
Once installed this script will handle the various updates. You change the version in the target settings, the script handles the rest. And your copyright is updated too.