Manage multiple versions of app easily with Git

// January 16th, 2012 // By LordBron // App Development, iDevBlogADay

With the proliferation of free, lite and full versions of apps floating around, sometimes I see people wonder how to manage them. This is just a short little post that talks about how I do it for one app that I manage for a client.

Use Git

The bulk of the work is actually handled by git. We have a free and 3 paid versions of the app. I won’t name the app, but I can describe how each version differs. The free version has a handful of assets to play with. Two of the paid versions are different themes of the same app. Each one has a larger set of assets that match their corresponding theme. The last one, also paid, is the same underlying app, but marketed to an entirely different customer base and again has a drastically different collection of assets.

What’s different in each app?

Basically, what’s different is the following:

  • Bundle ID
  • App Icon
  • Assets (images)
  • Maybe some button text

How does git help?

With git, I make a working version of the app. I then do a check in and tag it. I then modify all the above items for the next app. Check it in and tag it. You get the point.

For future versions (new features, bug fixes), I just checkout from those tags, reapply the new changes and then push to the App Store.

Granted, I could probably also use branches, but that seems like too much work because then I’m mentally tracking 4 versions of the app, which I don’t want. I want one app mentality, that just gets compiled 4 different times.

It’s been awhile since we talked code here and I thought that would be a good thing to share with the dev community.

I hope this works well for you too. Lemme know if you have any questions!

11 Responses to “Manage multiple versions of app easily with Git”

  1. Ken says:
    January 16, 2012 at 17:21

    Hey Tom,

    You can also do this by creating multiple targets in Xcode. You can include/exclude files in a given target so that different icons, assets, etc. are used for each one.

    This is how I manage the multiple versions of Charmed, Charmed Xmas and Charmed: RewardsDen Edition (previously Charmed Lite).

    Reply
  2. Justin Voss says:
    January 16, 2012 at 22:44

    Interesting technique, I hadn’t thought of using Git as a way to manage multiple flavors of the same app. Do you have to make the same bug fix four times, or does Git merging help with that?

    Is there any reason you decided not to use one project with multiple targets? It sounds like the apps have more in common than they have differences, which I think is a good fit for a multi-target approach.

    Reply
    • LordBron says:
      January 17, 2012 at 03:53

      Git merging definitely helps with that. It makes it so easy that I can update all 4 in under an hour, once the fix is coded of course.

      I think (aside from what I told Ken) I think part of my fears is that they will eventually diverge in greater ways and somehow, having the ability to branch and then later merge back in via git gives me a sense of confidence.

      Reply
  3. Bartek says:
    January 17, 2012 at 13:04

    Sounds like a lot of repetitive work everytime you need to publish a new version. I would stick to multiple targets, like I do with lite version of my app: http://xperienced.com.pl/blog/building-lite-version-in-5-easy-steps

    Or if you prefer git to handle this for you then I think the better would be to create multiple branches, commit a change specific to each of them once in every branch and then rebase to master every time you need to get a new release. This way you get your change applied on top of your latest (master) version and you don’t need to repeat this all over again.

    Reply
    • LordBron says:
      January 17, 2012 at 13:21

      Yeah, point 5 brings up a good point that I forget. Coming from a scripting world, the whole preprocessing of code based on target version is something I definitely forget about.

      Is there a way to show/hide code based on target versions to auto hide/show code wrapped as you demo’d in point 5?

      Reply

Leave a Reply