A bit of background:
My five-person team, four developers and QA, just finished a rather large project (50k + lines of code), which used a significant amount of Storyboarding. We have at least 10 different storyboards, many of which are at level 5 or 6 in the navigation structure.
In addition, we rely heavily on version control through Perforce, with dozens of checks per day.
My experience:
I never had to even think about dealing with the solution to any of our storyboards. They do great version control for two main reasons. Firstly, if you open one of them, you will see that it has well-structured XML that works well with the version. Secondly, with storyboards, you always want the layout of the entire user interface structure before any details or code are added (which is the whole point). This is very suitable for solving a team command, simply because each member can then take a separate ViewController and implement it, while remaining isolated from the rest of the team’s efforts.
However, I would recommend making some "shards", because you can easily get a giant nest of compounds with rats.
Finally:
If you look a little on the Internet, you will find many negative answers to Storyboarding, because it can get "dirty" to transfer data one at a time from one species to another. However, if you fall into this situation, you have already violated the basic principles of MVC. You should not use your views to store and manage data. At first it is tempting and easy, but in the end you will run into problems, as your project goes beyond the basics.