In my code I check the current version of the software on launch and compare it to the version stored in the user's data file(s). If the version is newer, then I call different methods to update the old data to the newer data version, if necessary.

I usually have to make a new method to convert the data with each update that changes user data in some way, and cannot remove the old ones in case there was someone who missed an update. So the app must be able to go through each method call and update their data until they get their data current. With larger data sets, this could be a problem.

In addition, I recently had a brief discussion with another StackOverflow user this and he indicated he always appended a date stamp to the filename to manage data versions, although his reasoning as to why this was better than storing the version data in the file itself was unclear.

Since I've rarely seen management of user data versions in books I've read, I'm curious what are the best practices for naming user data files and procedures for updating older data to newer versions.

Edit: The 'date stamp' stemmed form a discussion here:


Since the question is too open-ended, I should say I'm looking for the recommended procedures for upgrading user data between versions.

If possible, it would be nice to see iOS / objective-c practices, but it's not required.

  • 3
    What does your question have to do with any of your tags?
    – DeadMG
    Commented Nov 27, 2011 at 16:52
  • I've retagged the question. If you want language specific answers please add the language(s) you are using in the question and tag appropriately.
    – yannis
    Commented Nov 27, 2011 at 17:35
  • Those tags are much better, thank you. I used the languages as I'm curious how others handle upgrading user data in those languages. Commented Nov 28, 2011 at 2:44

4 Answers 4


Dates are helpful for when you need extra information about when something was happening. There is no harm to adding them to a file that already contains a version number.

However, you can not use a time stamp as the sole indicator of what version is running, therefore deciding what needs updating. Just because you released 2 updates in the last year does not mean that someone with an install date within that range is using one of those two versions. If the user gets a copy of the installer, they can hold on to it for future clean installs and expect the software to update itself instead of getting the newest version.

  • There's no indication this file is dynamically named during the installation process. The date is just placed here instead of within the data file instead of a version number.
    – JeffO
    Commented Nov 27, 2011 at 17:12
  • @JefO: If the date is not dynamically generated, then all it is is a unique identifier. No different than a version number, just a different format. If the question is about a file who's name is the date vs. a file that contains the date, then I see that as an implementation detail. Any benefit would depend on the languages API for reading from a file vs finding a file in a directory. Commented Nov 27, 2011 at 17:22
  • Please see the updated question regarding time stamps. Commented Nov 28, 2011 at 2:48

As you've noted there is no real advantage of a date over the version number. And you do need to keep old conversions in order to support people who skip updates (my wife is bad at that).

One thing you might think about is some kind of inventory of the number of people on each version so you would know when you could drop old updates. Apple should be able to provide you with those statistics (but I have no clue if they do). Or you could possibly add a ping function that would send you the version number and some unique id each time the app is run for the first time after an installation or upgrade.


The immediate benefit of a timestamps I can see is that you then have a sequence. I'd recommend the timestamp be inserted into a constants file, though, at build time. This makes the timestamp indicative of the build version (not the time of installation/upgrade).

Other than that, though, I'd say it's up to you. You can easily write a class to help out with version sequencing, depending on your version naming method (1.x, 1.2.x, etc.).

  • Please see the updated question so you can see more about what I'm referring to. Regarding your answer, why even use a time stamp and simply use the version number, since the goal is to identify the version number anyway? Commented Nov 28, 2011 at 2:47
  • @Javy That's kinda my point - I don't see a real advantage to using a datestamp over the versioning you are already using for the software on the deployment side. I did just think of, though, the fact that your development build would benefit from micro-updates between versions. This would allow you to use the same data update framework without having to run manual update scripts on your dev data. Of course, you could just wipe your dev data when needed.
    – sarumont
    Commented Nov 28, 2011 at 15:03

In terms of iOS / objective-c, one of the best practices is to use key-value data, along with NSCoder. This allows you to update older data in a fairly straight forward manner.

Another option is to simplify things down to an NSDictionary and save the data out in JSON format (or similar). This has the advantage of significantly simpler common use, re-ordering of data elements between versions is easier to handle (typically you don't have to do anything) but the drawbacks of placing limitations on the data types that can be used and having to check for missing values as a separate process.

If the format of the value for a key changes you can, in some cases, get automated conversion during load (ex: [dataValue intValue] -> [dataValue stringValue] if dataValue is changed from an integer to a string). If needed, you can check the type manually (isKindOfClass/isMemberOfClass) and covert as needed.

As to whether or not to use a date stamp in addition to a version in the data, that depends on what you are attempting to accomplish. If you are just wanting to track compatibility of data between releases of the application then a date stamp has no more meaning than a version # (and perhaps less since it's harder to relate back to the app).

Personally, I use the the NSDictionary/JSON method where I can, and only use the NSCoder setup when I have complex data. If you have large structures that you feel may need updating several times over the course of your application's life span the I'd suggest using the NSCoder setup since it provides the cleanest method of updating data on the fly with the least amount of overhead.

Lastly, for straight C I use a setup for structures that provides simple version checking and data verification. Each struct that I (may) need to be able to update is layer out something like:


Version # is readable in a hex editor (ex: 0x00010000 == 1.0) and the tag is a 4 byte ResType (ex: 'pDat', 'TXT2', etc). I put the id_tag at the end after running into instances of other programmers updating my structures and not updating the version #. Doing so would cause any code attempting to use new data to fail because it's check to validate the data based on the old version # would not find the id_tag in the correct spot. It's not full proof (changing a 4 byte int to a 4 byte float would go unnoticed for instance) but it's decent, cheap, and helpful when viewing a data file with a bunch of these structures in a hex editor.

Hope that helps.

  • 1
    regarding iPhone development, I use KVO almost exclusively (even though I should be using Core Data sometimes). I've been using a file with no version or time stamp in the name. I've found it easier to check the version bundle, and in the NSCoding init methods I do a check against that version, then adjust the data as needed there. Commented Apr 30, 2012 at 12:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.