uikit - iOS Storyboarding - practical experience re: multiple developers? -

There is a great way to deal with the storyboard with many view controllers in iOS, and the transition between them.

However, I have not been concerned with them yet, when more than one developers change to see the controllers in the same storyboard file, and as a result the controversy tributes Looking at what is happening / P>

Has anyone had a more practical experience with this, which is in production of moderate complexity?

What is your assessment - is storyboarding ready for "prime time" in this regard? Or is it better suited for single developers or small development parties?

(And how many storyboard files are about 'fatigue' such action?)

Opinion?

A little background:

My five-person team, four developers and QAs, have just finished a major project (line of 50k + code) which used significant amount of storyboarding. We have at least 10 different storyboards, many of which are going from depths of 5 or 6 levels in navigation structure.

In addition to this, we rely heavily on version control by Perforce, with dozens of check-ins per day. / P>

My Experience:

Never did I ever have to think about handling a resolution with any storyboard. They are very well controlled with version control for two main reasons. First of all, if you open one, you will see that it is a well-structured XML that plays very well with the version. Second, with the storyboard you want to take your entire UI structure (this is the whole point) before adding any description or code always . It lends very well to a team coding solution, because each member can then take a different view controller and apply it, the rest can be different from the team's efforts.

However, I have some 'sharding' because you are getting a huge mice nest of the connection with ease.

Finally:

If you look around a bit online, you get many negative reactions to storyboarding because it is visible from one view To pass the data till now can be 'useless', however, if you are achieving yourself in this situation, then you have already violated the fundamental principles of MVC. You should not use your ideas to store and manage the data. It's tempting and easier than ever, but eventually it will bother you because your project goes beyond the basics.