Proper setup of XCode iOS project?

Question

I would just like to find out from some more experienced developers what the proper setup should be for the following situation.

We are building iOS apps from the App Store. The base code should be the same for the various apps, as the functionality is the same. However, each one should receive different pre-compiler information (which I know is easy via the plist file, so no problem there). Now, each of the apps should have different resources. Images, sounds etc etc. (Currently I have all the resources in different folders, named the same so I can just drop it in at any time and the app will change, but it seems.... dirty to say the least).

Should I create the initial version, then create new targets and copy everything over? Or should we duplicate the target? How then do I specify the different resource folders?

Thanks

---

@j_mcnally

Do you suggest the following:

CORE_PROJECT
 |
 |-- APP 1 PROJECT
 |    |-- target -> free
 |    |-- target -> paid
 |
 |-- APP 2 PROJECT
 |    |-- target -> free
 |    |-- target -> paid
 ...

and then the CORE project just should not have any targets? Simply the shared sources? Seems logical to me. Any other comments?

Answer 1

you can embed a project inside a project. so you could have a core project, and then embed it in your parent more specific project. this way you should be able to reference the same core code but build different targets.

Answer 2

How similar do you really intend these apps to be? If the goal is for them to differ only in some of their configuration then I prefer not to maintain duplicate targets or projects. I believe that redundant configurations which aren't supposed to change but which the other developers and I must try to keep in sync are an invitation to introduce inconsistencies which will cause bugs and may ultimately fork the projects unintentionally.

Instead I try to automate the entire process and avoid creating duplicate configurations wherever possible. I would add a run script build phase as the first step in your build process which symlinks or copies the set of resources appropriate for the current app into postion before performing the build. That way you can allow an environment variable to select which set of resources are used by the app. Developers should be able to add non-shared schemes to their local workspace if they want a convenient way to set and swap those environment variable values when building from within xcode.

I've found this to work very well for small configuration changes like switching an app to communicate with development/staging/production backend systems and I've missed having that same level of consistency when working on a large project which set out to build multiple apps based only on different sets of resources but which rapidly diverged into incompatible systems sharing a single code base.

Now if you think there will be a real need to add unique behavior to these different apps then I suggest creating a shared static library build target for the common code which can be included by the application build targets for each app. Share the whole cluster as a workspace and developers can switch apps just by selecting the appropriate scheme. That should keep a clean separation between shared and app specific code without adding much overhead. As the apps grow and stabilize you might eventually want to branch into multiple repositories with the static library project as a common dependency of the others. That will introduce a cost to working on both an app and the shared library but that may be desirable if you have to be cautious about making changes to that shared code base. Multiple repositories will also allow each app to lock to specific revisions of the shared libraries and control when they accept new changes, depending on your process that could be seen as good or bad.