-4

I'm simply trying to design a database schema upgrade scheme (for a family of applications using a proprietary database). What I'd like to have is a simple way to determine that the application has been reinstalled on the phone, with a different Xcode-generated version of the app from the previous version, so that we only go through the messy upgrade logic if there's been a change.

I considered simply using a timestamp of __DATE__ and __TIME__ stored in the app settings, but that captures only the compile date of the module containing the constants, and may miss builds that didn't force that module to recompile. And I suppose one could use the date on the bundle file, but that seems mildly flaky. (Any experiences with that scheme would be appreciated.) I looked for a build date stored inside the bundle but so far have not found anything.

Actually looking to see if there is a mismatch between the installed and coded versions is too expensive to do on every startup.

And of course I'm trying to avoid a scheme that requires manually modifying a version identifier in the app, since humans have a tendency to forget such things in the heat of battle.

(I'm fairly confident that someone is going to "dupe" this question very quickly. I don't mind that so long as the dupe really is addressing my question, and not just something that hits the same keywords.)

rmaddy
  • 314,917
  • 42
  • 532
  • 579
Hot Licks
  • 47,103
  • 17
  • 93
  • 151
  • Don't you have to increase the build version anyway if you send a new version to the App Store? Or is this for internal builds and testing? - There are also Xcode action scripts to modify the Info.plist automatically with each build (to avoid the "human factor"), e.g. http://stackoverflow.com/a/11112042/1187415. – Martin R Jun 28 '13 at 16:47
  • @MartinR - It's for internal and external builds. – Hot Licks Jun 28 '13 at 16:49

2 Answers2

4

I've implemented this for multiple apps across multiple companies. There are many feasible approaches, but the simplest seems to be simply storing your last launched version in NSUserDefaults and comparing that, at each launch, to the current version.

You can fetch your bundle version:

NSString *version = [[NSBundle mainBundle] objectForInfoDictionaryKey:(NSString *)kCFBundleVersionKey];

You can save/read it:

[[NSUserDefaults standardUserDefaults] setObject:version forKey:@"lastVersion"];

There are also ways to auto-increment your build numbers so you never forget: like this

I'd highly recommend this approach over any sort of timestamping.

Community
  • 1
  • 1
Jerry Wong
  • 91
  • 5
2

A good solution is to have a "version" value stored in the database. Start at 1 and go up by 1 each time you update the schema. Each time you open the database you check the value in the database. If it doesn't match the latest version then you can execute an upgrade script you provide with the app.

I do this with an app that allows users to backup and restore their data. Since they could restore older data, checking the app version is useless. I need to look at the version stored in the database file. I have separate update scripts for each version of the database I have ever released so my app can restore data from any version of my app.

rmaddy
  • 314,917
  • 42
  • 532
  • 579
  • @MartinR I just got serial down voted for some reason. I'm waiting to see if it gets cleaned up automatically. – rmaddy Jun 29 '13 at 17:54
  • Whom did you annoy? ... Just kidding, I hope it will be reversed. – Martin R Jun 29 '13 at 18:01
  • 1
    @MartinR Thanks for the reversal (I assume it was you). Time will tell if it gets cleaned up. I guess that's what I get for explaining most of my down votes instead of just doing it anonymously. :) – rmaddy Jun 29 '13 at 18:05