0

The situation:

I have a basic app with some central functionality.
My clients (potentially many dozens) all want their own customized apps in the app store.

The problem

If I have dozens of apps in the app store and I want to change some of the core functionality, I would have to update each file in the corresponding project, compile, go through iTunes Connect, upload etc. Every small change could potentially take days of mindless work.

The question

Is there a way I can use a versioning system like git to administer the parts of my code with the core functionality separately, so that all projects are updated automatically when I commit a change to the core files?

Is there any other way to make this process easier to manage?

Mundi
  • 79,884
  • 17
  • 117
  • 140
  • FYI, what you are talking about is called white labeling: take an app's core functionality rebrand/customize it for clients. – memmons Aug 23 '11 at 16:32

4 Answers4

2

Typically if you have some core functionality that you need to reuse in iOS you'll either create a static library that you can include in your other projects or (if the core functionality includes things like assets which can't be included in a static library) you'll have a sub-project. In both cases, though, you'll want to make sure each of your app projects has a target dependency with your core functionality project so it is always rebuilt with the latest changes.

  1. Create a MundiCoreFramework xcode project that has all your core functionality and which compiles without having to reference client-specific code
  2. Create a git repo for this core framework project
  3. In each of your app projects that use this core functionality, add the MundiCoreFramework as a git submodule and add it as a subproject to the app project.
  4. Whenever you update the core framework you can issues git sumodule update for each app and recompile.
memmons
  • 40,222
  • 21
  • 149
  • 183
  • Thanks. I am trying to figure out how to evaluate these options. – Mundi Aug 23 '11 at 17:50
  • A sample project is probably the best way to play with your options here. As far as I can tell the three solutions that the three of us have proposed all ought to work. It's going to come down to which method is easiest for you to work with. – Dan Ray Aug 23 '11 at 18:10
  • @Harkonian the Downvoted Please elucidate me on how to include the MundiCore into the various client projects. Do I copy them? How are they going to know from where to be updated with `git submodule update`? – Mundi Sep 14 '11 at 20:17
  • What do you think about ravuya's solution? How does it compare to yours? – Mundi Sep 14 '11 at 20:29
1

I'm not real familiar with the Xcode "target" structure, so that may in fact be a better approach. But you can definitely use git for this.

Probably you want a "master" branch where all the universal stuff lives, then a branch for each "customized" version of the app.

When there are changes in the master, you'll merge those changes through each of the custom branches. Then from each branch, you'll build a product to submit to the store.

In each branch, you'll separately set the app id, whatever art and text changes are needed from one version to the next, whatever key setup is appropriate to this version, etc. All those settings can stay local to the custom version branch.

This is a perfectly valid workflow in git. It's not how most people use it, but that's because most people are headed to ONE production product, not many.

Dan Ray
  • 21,623
  • 6
  • 63
  • 87
  • Thanks a lot for this feedback - sort of the opposite of @ravuya's approach. I am still evaluating... – Mundi Aug 23 '11 at 17:46
  • So that would mean that for each client project I would have to do a _reconcile_. I guess that's also a lot of work, right? Is there an automated way that only some files have to be reconciled, others will be automatically? Perhaps using `.gitignore`? What I like about this approach is that these branches would all be transparently visible on the git server... – Mundi Sep 14 '11 at 20:12
  • I'm not familiar with "reconcile" as a git keyword. It would take *merging*. And it would take the discipline to make universal changes in a master branch and then merge those changes into each of the customized version branches. All the tools you need to automate that are right there in git. – Dan Ray Sep 14 '11 at 20:29
  • I am going with this option for now. Updating apps is quite smooth, but still takes some time. But everything works as expected. Thanks everyone for your help. – Mundi Dec 14 '11 at 11:40
1

Another option might be using git submodules to organize common code, and then have each individual project simply add your common code as a submodule.

ravuya
  • 8,586
  • 4
  • 30
  • 33
  • Thanks for this feedback - I will check it out. (Needs some time.) – Mundi Aug 23 '11 at 17:40
  • In *Pro Git* it says: _Submodules allow you to keep a Git repository as a subdirectory of another Git repository._ So I should create a subdirectory / subproject for each client within the main project directory, right? Then committing the main project would also save all the sub-repositories - or not? Or I have to `.gitignore` them... Is this the setup you propose? – Mundi Sep 14 '11 at 20:09
  • What do you think about Harkonian's solution? How does it compare to yours? – Mundi Sep 14 '11 at 20:28
  • Their solution is effectively what I proposed. You will create multiple Git repositories - one for your library, and one for each "dependent project" - and import the library repository to the project repositories as a submodule. The git community book (http://book.git-scm.com/5_submodules.html) walks you through a demonstration with some mocked up test repositories. – ravuya Sep 14 '11 at 21:34
0

You can use Target to customize the app for each client, this would mean that you could keep one code base and have multiple apps with the same code base.

This will not solve the updating the app in the appstore part, which you would still have to do by hand as var as I'm aware of.

rckoenes
  • 69,092
  • 8
  • 134
  • 166
  • That sounds like a good start... But it seems that the project would then become pretty much a monster project with many Default.png, Icon files, perhaps even appDelegates... – Mundi Aug 23 '11 at 15:15
  • Yes, but you can exclude/include resources per target, if done it for some of my project and it works really well. You can even have some classes per target, so you can change the working of them per target. – rckoenes Aug 23 '11 at 15:39
  • This is a incredibly bad approach. I've tried it before and the project becomes fragile very quickly. Combining 2 projects this way worked ok -- 3 started to become troublesome and after that trying to keep the project file working correctly was a nightmare. – memmons Aug 24 '11 at 17:03
  • @Harkonian What are you using? – Mundi Aug 28 '11 at 13:16
  • I'm using the solution I posted above in my answer. I've been through this very same process with some rather complex projects and I've tried a number of different approaches -- including this one. At the end of the day, the only sane way for me to manage those projects was the approach I posted above. – memmons Aug 28 '11 at 15:34
  • @rckoenes I have decided against this approach. I think it is ok up to a couple of targets, but not more. Thank for your input! It's appreciated. – Mundi Sep 14 '11 at 20:18