あなたの質問をNIBとストーリーボードの2つに分けます。
NIB に関する限り、ソース管理の問題は面倒ですが、主に View Controller ごとに 1 つの NIB ファイルを持っているため、扱いやすいものです。2 人の開発者が、NIB を利用したアプリの 2 つの異なるセクションで、マージの問題なしに作業している状況を想像できます。アプリケーションの UI のすべてではないにしてもほとんどを記述する 1 つのファイルがあるため、ストーリーボードは異なります。明らかに、そこには紛争の問題が発生する可能性がはるかに高い.
NIB は、正しく使用すれば、非常に便利で時間を節約できます。次に例を示します。iPad の iPhoto アプリには非常に複雑な UI があります。その UI の大部分は、プログラムによってレイアウトされます。ただし、アプリはNIBを使用してグラフィック要素をロードし、コードでレイアウトします。これがブラシ パネルの仕組みです。すべてのブラシは NIB で作成されます。これは、Appleが何十もの同一のイメージ/イメージ ビューの割り当て/初期化コードを用意する必要がないことを意味します。すべての作成は NIB で行うことができます (これについては、iPhoto UI に関する WWDC 2012 セッションで詳細に説明されています。追跡する価値があります)。
そのため、NIB は良い場合もありますが、多くの時間を節約できます。また、マージの問題がありますが、多くの場合、それらは簡単に管理および処理できます。
次に、ストーリーボードに行きます。ストーリーボードは面白いです。一方で、それらはプラットフォームに不慣れな単純なアプリや開発者にとって非常に便利で便利です. ベースのアプリを NIB からストーリーボードに変換したUINavigationController
ところ、時間を大幅に節約できることがわかりました (特に、ストーリーボードを使用するとプロトタイプ セルを利用できるため、テーブル ビューに関して)。
ただし、複数の開発者が参加する大規模なプロジェクトに取り組んでいる場合、ストーリーボードがそれほど有益であるとは思えません。おっしゃる通り、マージの競合には大きな問題があり、NIB とは異なり、単一のストーリーボード ファイルがアプリの UIをすべて制御するため、競合を解決するのは簡単ではありません。
これが私が提案するものです (私を無視してください!) - 現在アプリを開発していて、レイアウト/UIを完全にコードで行っている場合は、NIB が時間を節約できるかどうかを検討してください。万人向けではないかもしれませんが、少なくとも検討する価値は十分にあります。NIB を実際に使用している大規模なアプリの数に驚かれるかもしれません (前述の iPhoto だけでなく、Apple が提供する多くの組み込みアプリや、大規模なチームによる多くの人気のあるサードパーティ アプリも同様です)。かなり単純なナビゲーションを備えたアプリに取り組んでいる唯一の開発者でない限り、ストーリーボードを検討することはおそらくないでしょう。絵コンテを軽視しているわけではありません。私は絵コンテを使うのが大好きです。ただ、コラボレーションにはあまり適していないというだけです。
誰かがあなたの質問に答えてこのコメントを投稿しました - 私はそれについて議論したかったのです:
ストーリーボードでできること、コードでできないことはありません。オブジェクト、ジェスチャ レコグナイザ、セグエ、さらには制約 - すべてプログラムで構築できます
これは技術的には真実ですが、実際にはストーリーボード/NIB にはコードよりもはるかに簡単なものがあります。これの良い例は自動レイアウトです。自動レイアウトの制約を完全にコードで管理することは確かにできますが、厳しい現実として、ASCII 自動レイアウト表現は、IB で得られる視覚的表現よりもはるかに扱いにくいということです。これは特にXCode 5 に当てはまります。IB の自動レイアウトが大幅に改善されています (まだ NDA の下にあるため詳しくは言えませんが、Appleはここで変更について少し公開しています)。