Xcode 4 with two interdependent projects: should I use the git submodule?

Question

I am working on an iOS application and have broken the code into two separate projects: the client library for the web service and the application project, which depends on the client library.

Both projects have been added to the same Xcode workspace with the corresponding declaration.

Each project has its own git repository. Currently, I have two projects checked for two separate directories, and I manage two git repositories independently of each other. The only place where the relationship between the two pieces of code is currently defined is the Xcode application project.

However, I am wondering if the git client library repository should be added as a git submodule in the application repository. This seems conceptually correct, but I haven't used git submodules before, and I'm wondering if there are any problems using this approach with Xcode?

(I can find many blog posts on how to use Xcode workspaces to manage dependencies between projects like this, and elsewhere a lot of documentation on git submodules, but I can not find any verified account and verified workflow for use both together. If you know one, please send a link!)

Answer 1

I participated in projects that did this before using the following layout:

* app-workspace * App.workspace * library [submodule] * Library.xcodeproj * library sources * app [submodule] * App.xcodeproj * app sources 

In this way, the workspace is aware of design and assembly schemes. The git workspace repository knows about submodules containing projects.

In practice, this requires a lot of effort in order to update the definitions of submodules at the top level, so we usually worked on the main branches of submodules. The transfer of certain versions to the workspace submodules occurs when important changes are added: it is not too rare if the CI system is built from a top-level project.

Of course, for unit tests, you can specify the CI in each submodule yourself, these are only integration tests that will require the entire workspace. The important step to remember here - and the one I sometimes messed up with - is that you should only update the definition of the submodule to a specific commit after you have pushed this commit to a common source of CI repositories and developers. If you forget about it, you risk breaking the control over other people when the parent project refers to fixing a submodule that they don’t have.

The place where potential issues with interacting with Xcode can potentially occur is to define your build schemes. The approach I recently made was to use the schematic editor to define the schemas that I want to use as general (instead of each user), and defined in the workspace at the top level, and not in projects in submodules, after that and those schema definitions, that were taken to git, turn off automatic schema creation. Now all your developers and the CI system all agree on how to create your product.

Answer 2

Using submodules makes sense for what you do. Especially if the client library is not going to change much.

And this means that other people coming to your repository know that the library is a separate project, as well as partitioning.

Sometimes I find that the repositories embedded in the submodules have been crippled, but usually it's just a matter of removing and adding them back.

At the root of the main project:

 git submodule add <path to repo> git submodule update 

It should be all you need to use.