28

I am developing an iOS app. Right now it is one app and two targets (app and tests).

Getting closer to publishing I want to split this app into three apps with lots of shared code and shared tests. (Think of free version and full version for App Store and prototyping app that will not be published).

Would you set up multiple projects in Xcode (1 library project and 3 app projects) or keep all in one project and only set up multiple targets?

Miriam
  • 1,158
  • 1
  • 13
  • 23
  • I tend to favor the single project approach as I'd like to keep my one and only git repository and also it sounds less cumbersome to me. On the other hand Xcode User Guide recommends to set up one workspace with multiple projects. My concerns with the latter are: It is a bigger change for my current structure. Plus it sound scumbersome, from what I see here on Stackoverflow a lot of people seem to have issues to get dependencies right in a multi-project setting. – Miriam Jun 21 '13 at 09:51
  • I have 5 apps that come off of the same code base. 4 are related enough that I can use the same project with 4 targets, but 1 is pretty different so it has its own project. Both of the projects draw off of the same Git submodule for their base with their own repos on top. – borrrden Jun 21 '13 at 09:58
  • @borrrden: Thanks. Am I correct: Your reason for splitting off the pretty different app is a structural - lot's of non-shared code just for this app? So it sounds like I can start with the single project approach and leave further restructuring for "maybe later". – Miriam Jun 21 '13 at 10:07
  • 1
    Yes, well they are digital textbooks. I had 4 English textbooks, and 1 Japanese textbooks. The English ones were almost identical in terms of functionality, and only differed in content. The Japanese textbook had a lot of different features though, but also many shared core features like page display, page navigation, login, etc. – borrrden Jun 21 '13 at 10:09

2 Answers2

32

I think you have at least 3 options here:

  1. Separate projects. It is more difficult to share code across projects, but with Xcode workspaces this is quite feasible. If you have a lot of customization for each project, this might make sense.

  2. Same project, more targets. This is the usual way this is done. It is very easy because you have a very neat overview of what files go into which target. If you have around, say, a dozen or so targets, it is really quite easy to handle.

  3. Separate git branches. I have worked with this in the past. The differences between the apps (Info.plist, configuration files, data files) are just swapped in the corresponding git branch. This is practical if you have a lot of data and don't need to have all of it available at all times. However, the complexity of git is considerable if you are not familiar with it. You can create git submodules to change the shared code parts in one go.

Mundi
  • 77,414
  • 17
  • 110
  • 132
  • 1
    Submodule is a way of accessing another repo, from inside a repo. However, it is very poorly designed (IMO) and messes things up when you have branches. For a very similar purpose, I ended up creating several projects inside the same folder and kept majority of the codebase in only one (with the other project referring to those). I manage all the projects from the same Git repo and I can easily manage which files to add/remove in the respective project files. – Ege Akpinar Jun 21 '13 at 10:25
2

I would suggest you a hybrid approach depends on your needs

  • If you need several applications - create Target, that is exactly what they are for. You can handle sharing files using Target Membership[About]

  • If you have source code which can be separated into module - create additional Project (for shared source) inside Workspace. This technic is used by CocoaPods

[Xcode Workspace vs Project]
[Xcode components]

davidev
  • 5,693
  • 3
  • 7
  • 32
yoAlex5
  • 13,571
  • 5
  • 105
  • 98