CODEWITHSUNDEEP
iosobjective-cxcodeversion-control
rfsbsb
rfsbsb

Reputation: 519

How to manage shared resources in iOS team development?

I'm starting a new small study project and I will work together with a friend. We will work on the same project, but on different parts. Sometimes we will need to modify files that are common.

My question is: how do you guys manage this kind of project? My biggest concern is about storyboard file and some other shared resources.

Any advice would be great!

Upvotes: 2

Views: 408

Answers (2)

bcattle
bcattle

Reputation: 12819

@Dima mentioned that NIB files are hard to merge, this also applies to project files. Some ways to deal with this:

  1. Lay out the whole file and class structure ahead of time
  2. Have a single member of the team who is responsible for maintaining project structure, and if anyone wants to add/move/rename a file they get the "project master" to do it
  3. Divide the app up into a series of different static library projects, and assign one person to each

Using static libraries is one of those things that is much much harder than it should be, but once you figure out the right combination of obscure changes to XCode's build settings everything works well.

In a nutshell, you need to

  1. In the static library set "skip install" to YES, and make all header files public
  2. In any projects using the library link it in in "build phases" and add a header search path so it knows where to look for the header files.

See the following links for the step by step:

You could also use a dependency management system like CocoaPods to automate some of this static library configuration and build. See here.

Finally, this answer also has an interesting approach to avoiding xcproject conflicts: instruct git to "always union" the merge. Haven't tried this myself.

Upvotes: 1

Dima
Dima

Reputation: 23624

There are a bunch of things you can do here and not all of them are absolute, so here are a few of my opinions.

  1. Use Git. Most simply would be to use a service like github or bitbucket.

  2. Each person should create new branches for grouping all the commits for a particular change/feature and then merge the feature branches into your release branch.

  3. Have a good gitignore, here is github's objective-c gitignore as an example.

  4. If your team will be growing or there is a good chance you will be working on the same pieces at the same time, don't use storyboards or xibs in general. These are a really bummer when you have merge conflicts and generally don't behave well with multiple people working on them. I recommend laying out all of your UIs in code either with autolayout or without. This in my experience also makes UIs way easier to debug, refactor, and update.

Upvotes: 2

Related Questions