1

Greetings Stackoverflow Community,

I have taken on the task of 'unifying' 4 mobile iPhone apps that share 95% of the code and differ only in 5% (this is somewhat of an over-simplification, but never mind). Each of the apps has its own hefty set of resources (media files).

After 'unifying' the 4 apps, I will be adding new functionality to the apps, mostly functionality that the apps will share.

I would appreciate hearing your opinions on what's the best way to manage the code of these apps. Here is the approach I'm taking at the moment.

  1. I'm maintaining only one Xcode project which includes the functionality of all 4 apps. The functionality that is not shared among all apps is enclosed in a condition such as: if (appName == 'X')...

  2. Each app has its own info.plist file, so I have 4 of such files: infoX.plist, infoY.plist, ...

  3. Before I build an app, two things are done: a. in the Build Settings, I specify the name of info.plist to use. b. I ensure that only the app's resources (media files) are in the project. I delete the other apps' resources.

As the apps are 95% similar in their code, having only "One App to Rule Them All" ensures that when the code gets upgraded, all apps enjoy the upgrade. You can assume that the apps will remain very similar in their code.

As the apps' media files are large and many, I'm keeping them off the Git repository.

How does this all sound?

Many thanks!

Sleiman
  • 1,620
  • 1
  • 12
  • 16

2 Answers2

3

There are better ways:

A. Move to framework

It depends on how generic are common parts of the apps. But you should think about putting parts of it in a separate project that is a framework. You can link your 4 apps against that framework. But, of course, not everything will go there.

B. Have different targets

For sure you should have 4 different targets. Xcode let you set build settings for each setting commonly per project or specially per target. Additionally you can customize the build phases (including copy of the media files) on a per target base. So you do not have to rename or delete and insert anything. You simply select a target, you want to build.

C. Project tree

Xcode allows you to have subprojects with common code. Maybe things like common "foundation" classes of your app. You can have different projects for each app in a single workspace, all using the subproject.

Probably the best way is a combination, depending on what is the subject. However I would start with B. and likely add the other techniques, if needed.

Amin Negm-Awad
  • 16,582
  • 3
  • 35
  • 50
  • Thanks Amin! Having just read about creating multiple targets for the same app, approach B is quite promising and I reckon it is worth implementing in my project. Thanks for your time! – Sleiman Apr 22 '15 at 20:51
0

I encountered more or less the same case, and we decided to use one Xcode project with multiple targets. That way you can simply change the target before hitting the build button (or configure specific build scripts changing the target). In our project, we had a few files sharing the same names (in different folders), and associated each one with a different target. For example, we had three "Stylesheet.h/.m" with different UIColor & UIFont definitions stored in different folders, and each one of them was linked to a different target. Same thing for the "Localizable.strings".

Rufel
  • 2,630
  • 17
  • 15
  • Thanks Rufel! Defining multiple targets seems to be the way to go. I will start implementing it. – Sleiman Apr 22 '15 at 20:52