CODEWITHSUNDEEP
iosobjective-cxcodegit
Brian
Brian

Reputation: 733

Sharing Xcode Library between users

I am looking for the best way to share a "common" Xcode project amongst multiple developers on multiple apps. One developer will be working on the "common" Xcode project, while another developer will be working on a project that will use the source from the common code Xcode project.

Where I am stuck is how to set this up with both Xcode and Git so that when the developer of the common code library makes a change, the developer that uses that library will not have delete and re-add the Xcode project, or lose their work.

I have looked at some documentation with Git submodules, but there is a lot of debate around the topic and its usefulness. Are we better off just having one Repository with ALL the code for all the projects in it, that way everyone checks-in/out of the same place?

Thanks for the advice and pointers!

Upvotes: 1

Views: 452

Answers (2)

drekka
drekka

Reputation: 21883

There is no "best-way" in software development. There are always a number of solutions to any problem. The trick is working out which solution best fits you. Int his case there are a number of factors to consider - how your developers like to work, what sort of experience and back grounds they have, how you want to manage the code, etc.

I think there are a few solutions you need to consider. Pick one and try it out, but don't be afraid to change if you find it doesn't work or hack it around to suite your needs.

  1. One repo. Not usually considered the best solution because it restricts the ability to reuse code on other projects. In XCode you tend to end up with numerous build targets and highly complex builds. This can become un-manageable quite quickly. Also tends to make versioning difficult and can break things quite fast.

  2. Multiple repos and static libraries. There are a number of variations on this. The repos can be managed by Git independently or you can employ submodules. I would seriously consider breaking code out into projects that build static libraries. Using XCode workspaces you can have a number of projects open at the same time and arrange them as either siblings or nested child projects. This depends greatly on what and how you want to build them. Using Git submodules has the advantage that the submodules are effectively versioned which means that make changes to a static library project is not going to break everything that is using. The downside of using Git submodules is that they (IMHO) are not the most user friendly part of Git and take some getting used to. A good Git client is most useful in this. Sourcetree is free, but (again IMHO) Tower is easier to use and handles submodules better than Sourcetree.

  3. Using Cocoapods. Cocoapods is like using Maven or Ant for Xcode. It an makes things quick and easy to get running and automatically handles dependencies. However it also messes with the XCode project files, often requires manual intervention, adds additional compilations that you may not require and depending on how you setup your builds, can get in the way. Figuring out how to control the way it plays with your project files can also take some time. A lot of people like Cocoapods because it's initially easy to use and doesn't require the technical knowledge that Git Submodules require. Personally I'm not sure that bringing Java dependency management ideas into Xcode is a good idea in the long run.

Upvotes: 1

alex
alex

Reputation: 248

The way we share common projects/libraries is through the use of private Cocoapods. Its not pure git, but cocoapods do use git. You can read the official documentation on how to set up a private podspec repo : http://guides.cocoapods.org/making/private-cocoapods.html

There are also loads of possibly simpler explanations on how to set up a private podspec repo like this one

Upvotes: 0

Related Questions