Ask HN: Co-Development, XCode, Git and Storyboards. Is there a decent solution?

6 points by jgibfried 13y ago ↗ HN

I have had endless merge issues when working with other developers on iOS applications that utilize storyboards. After taking a gander around the internet for ways to solve the constant annoyance, I see two ways people are handling it.

1) Tiptoe around the commits. Just coordinate your work to minimize stepping on each other's toes. Which means constant 'I'm pushing changes to x storyboard now' and 'Are you working in y storyboard?' This is fine/mildly irritating with a two person team, but it would be hell with anyone else involved.

2) Granularity. Break your storyboards down into the minimum reasonable piece. This method means that it is less likely that you are going to be working on the same file. Although, this doesn't prevent conversations about who is working on what, it just minimizes them.

I ask you, good people of HN, is there another, better way?

3 comments

[ 111 ms ] story [ 1006 ms ] thread

rcirka 13y ago ↗

The solution I use is to not use storyboards. Although storyboards have some nice features, they don't work well in large projects. Merge commits are the big problem. The storyboard diagram can get huge. Also, storyboards don't handle the re-use of view controllers very well. My teams stick with using the traditional viewcontroller per nib model. I have read that some companies, such as google, forbid the use of nibs altogether.

Zev 13y ago ↗

Try marking your storyboards as binary files in git. It worked pretty well for me the last time I was working with a designer and using xib files.

eduardordm 13y ago ↗

Maybe you are structuring you application the wrong way, this is why you are having such problems.

My team manages a large app, this is how we do (and other companies we worked with too):

Every nib has only one responsible programmer (or pair) the storyboards uses many external nibs[1]. Storyboards are not meant to act as regular nibs, xcode will get insanely slow if you have a lot of screens. They will help you build prototypes faster, documentation and navigation flow but keep in mind that mildly complex projects will force you to have a bunch of bloated prepareForSegues around, which makes them useless.

[1] http://stackoverflow.com/questions/9251202/how-do-i-create-a...