6

I read some answers related to the same question, but I'd like to ask for something specific. When you have a HUGE project, imagine a big social network, even if you separate your UIViewControllers logically into separate UIStoryBoards, it still seems like it slows down the process. Every time you view any story board, it takes a while to render all of the UIViewControllers and it seems like a huge pain to deal with.

Now, for large projects, would you go for Nib files or is it better to stick to UIStoryBoards?

Dani
  • 3,427
  • 3
  • 28
  • 54

2 Answers2

11

If it is a large project with many view controllers and there is a team collaborating on it, I would recommend XIB. This is because each small team will not have to understand the entire flow of the project so no need a storyboard with these relationships. And another big advantage is that when they merge there codes together, it will be less likely to have a merge issue. You don't want to have a merge conflict for a storyboard, trust me.

If only yourself are working on this, having a storyboard will indeed show the entire project flow and make you understand things more. So my recommendation in this situation is that keep using storyboard unless the storyboard loads in an unreasonable amount of time.

Fangming
  • 24,551
  • 6
  • 100
  • 90
  • 1
    That sounds very reasonable! Thank you. Thanks to @JayDeep & Rashwan L as well – Dani Jun 24 '17 at 11:17
  • So are you saying that you won't have a merger problem if you construct a project with XIB files? – El Tomato Jun 24 '17 at 11:58
  • 1
    @ElTomato No, just less likely. So both storyboard and xib are xml file. On story board, its a giant xml file with detailed position of each element, constraint and stuff. So if someone in your team accidentally moves a view controller, you can end up having a merge conflict. For xib, since only a small amount people are working on each xib, its just less likely. Plus, even if you have a merge conflict on a xib, it will be easier to find the conflict and fix it, since the xml file will be way shorter than that of a storyboard. – Fangming Jun 24 '17 at 12:05
  • I normally use storyboards, but I avoid segues. I don't ever get conflicts on the storyboard. If the app is too big I might do storyboards per section – Fernando Mazzon Jun 24 '17 at 12:17
  • @FernandoMazzon To get a merge conflict, create two branches from master. In these two branches, move a same view controller a little bit left or right, and then merge back to master one by one. You will get a conflict for your second merge. And your source control engine may probably enter some text to the xml telling you where goes wrong, and then you have to manually pick one by a xml reader because XCode cannot open that storyboard anymore. – Fangming Jun 24 '17 at 12:38
  • 2
    Adding to the answer, If in your project you're reusing viewControllers a lot but with different services and it's highly to go from each ViewController to lots of other viewControllers, it's recommended to use Xibs, Or after some-point you have to go through LOTS of refactoring after realizing that you had to use Xibs from the start :) – farzadshbfn Jun 24 '17 at 13:37
  • @FangmingNing but this is a conflict that's trivial to fix. I meant real conflict :P – Fernando Mazzon Jun 24 '17 at 14:48
1

It is not to tell which one is the better. because which one is good to tell based on team requirement.

If you are a single developer, it is better to use storyboard because it consumes less time to load all views. but when If the team consists of many developers, use XIB, otherwise, it is not easy to merge the modules/tasks.

You can more read abouts pros and cons of using of both things here. http://codewithchris.com/xcode-using-storyboards-and-xibs-versus-creating-views-programmatically/

Jaydeep Vora
  • 6,085
  • 1
  • 22
  • 40