storyboardについて調べていたところ、StoryboardLintの作者の考えが興味深かったので該当のstackoverflowのエントリを抄訳した。訳はニュアンスが伝わればいいくらいの適当さです。
When to use Storyboard and when to use XIBs
どういうときにstoryboardを使って、どういうときにXIBを使えばいいか、何かガイドラインはあるかな。それぞれの長所と短所はなんだろう。どういう状況でそれぞれを使えばいいんだろう。
動的にUI要素を組み立てる場合にstoryboardを使えないってのは知ってるんだけど。
(Asked by affian at 2012/2/22)
Answer by henning77 at 2012/3/1
ぼくはXIBを使い込んだし、storyboardを使ったプロジェクトを二つ完成させたことがある。そこからぼくが学んだことはこうだ。
- storyboardは小規模から中規模で、画面遷移が素直なアプリに適している
- 画面が沢山あったり、それぞれが複雑に遷移するようなアプリには向かないし、綺麗に保つのがあまりに大変すぎる
- 開発者が複数人いるような大きなプロジェクトだと、storyboardは使いたくない。storyboardはUI全体で一つのファイルなので、平行して作業することができないからだ。
- 大きなアプリだと、storyboardを分割するのがいいかもしれない。ぼくは試したことないけどね。
- storyboardを使うとしても、XIBもやっぱり必要だよ。たとえば以前の二つのプロジェクトではいずれも、テーブルのカスタムセルのためにXIBを使わかければいけなかった。
storyboardはUI実装のための正しい方向だと思うし、Appleはもっと強化していくのだろうけど、単一ファイルで表現するというのはなんとかしなきゃいけないだろうね。さもないと、大きなプロジェクトではとても使えないよ。
まとめると、ぼくは小さいアプリだったらstoryboardを使う。そうでなければXIBを使うよ。
Answer by johannes-fahrenkrug at 2013/10/18
iOS7がでた今日このごろだけど、ぼくはstroyboardを使わない方がいいと思うね！理由はこちら：
- storyboardはコンパイル時に問題を検出できず、実行時に落ちる。 segueの名前をtypoしたり、接続が間違っていたとしても、それが分かるのは実行時だ。存在しないカスタムUIViewControllerを指定していても、それが分かるのは実行時だ。コードで書いていればコンパイル時に分かるのに。最近ぼくがつくった StoryboardLint があればこの問題はだいたい解決できるけどね。
- storyboardはすぐこんがらがる。 プロジェクトが成長するにつれて、storyboardはあっという間に遷移を追うのが難しくなる。複数のview controllerが複数のsegueで他の複数のview controllerに繋がっている様子はまさにスパゲッティだ。そうなったら、Interface Builderで拡大したり縮小したり画面をスクロールしたりして、view controllerとsegueがどうなっているのか頑張って探しまわらなきゃならなくなるよ。
- storyboardを使うとチームで作業するのが難しくなる。 プロジェクトに一つの大きなstoryboardファイルしかないのが普通だから、複数人で開発するのは頭痛の元でしかない。複数人による作業をファイルをマージするとなるとconflictを解決しなきゃならいなんだが、それがまたひどく大変なんだ！XcodeはstoryboardをXMLファイルとして生成するんだけど、それは人の手で作業するようには作られていないんだよ。
- storyboardを使うとコードレビューが難しくなる。というより、ほとんど不可能になる。 ピアレビューはとても良いことだと思う。でも、storyboardの変更をレビューすることはできない。diffをがんばって眺めても、その変更が正しいかどうか、他の何かを壊していないかどうかを解読するのはとても難しい。
- storybaordはコードの再利用を妨げる。 ぼくのiOSプロジェクトでは、一つのクラスに色やフォントやマージンなどを置いて、アプリ全体で使うようにしている。そうして、一箇所の変更でアプリ全体のスタイルを変更できるようにしているんだ。これがstoryboardを使うとなると、スタイルの値をいちいちコピーして埋め込むことになって、変更のたびにそれらを一つ一つ置き換えなきゃならない。置き換えをミスってスタイルを壊す確率も高くなるってわけだ。
- storyboardを使うなら、すべて二重に作業しなきゃならなくなる。 iPadに対応したユニバーサルアプリを作るとしよう。そのときstoryboardを使うなら、iPadバージョンとiPhoneバージョンをそれぞれ用意して、UIや遷移を変更するたびにそれらを同期させなきゃいけない。やったね！
- storyboardはコンテキストスイッチを要求する。 UIや画面遷移をいじるたびに頭とXcodeの画面を切り替えなきゃならない。あーめんどくさ。
- storyboardを使うとコードのリファクタが難しくなる。 コードのリファクタするとき、storyboardが要求することを守らないといけない。さもなきゃ実行時エラーだ。コードとstoryboard、二つの世界を同期しないとリファクタできないってわけさ。リファクタなんてするなってことかもしれないな。
- storyboardは検索できない。 Xcodeのプロジェクト内を検索する機能の対象にstoryboardは入ってないみたいでさ。マジ勘弁してくれよ。
- storyboardは柔軟性に欠ける。 コードだったらなんでもできるのに！特にアニメーションやトランジションを使って何か凝ったことをしたいとき、storyboardを使っていると大変だ。
- storyboardはview controllerの型を変更することができない。 もしある UITableViewController を UICollectionViewController や UIViewController に変えたくなったら、一度シーンを消して作り直し、すべてのsegueを繋ぎなおすという作業が必要だ。コードだったら簡単なのに。
- storyboardは余計な二つの責務をプロジェクトに加える。 つまり、storyboard XMLを生成するInterface Builderと、それをパースしてUIやcontrollerを組み立てるランタイムだ。これらにバグがあってもぼくらには手を出せない。
- storyboardはUIImageViewにsubivewを追加できない。 だれか理由を教えてくれ！
- storyboardは個別の view controller に Auto Layout の有無を設定できない。 storyboardのAuto Layoutの設定は すべて の controller に適用されてしまう。
- storyboardは後方互換性を失うリスクがある。 Xcodeはたまにstoryboardのファイルフォーマットを変える。つまり、今日作ったstoryboardが数年後、あるいは数ヶ月後でさえ、正しく開ける保証はないってわけだ。thoughtadvancesによる指摘なので彼のコメントも読んでほしい。
これらがstoryboardを使うのが嫌な理由だ。いくつかの理由は、XIBにも当てはまる。ぼくの経験したstoryboardを採用したプロジェクトでは、storyboardで節約した時間より遥かに大きなコストが掛かってしまった。
コードでUIや画面遷移を作るなら、制御やデバッグはより簡単だし、ミスも見つけやすいし、コードの変更を他の開発者にも説明しやすいし、iPhoneとiPad両方に対応するのも簡単だ。
もちろんいつもコードを書くのが正しいわけじゃないよ。iPadとiPhoneのUIが大きく違うなら、二つのXIBを作るのがいいと思う。
ここに挙げた沢山の問題はAppleが修正できることだし、また将来的に解決してくれると信じてる。
まあいずれにせよ、ぼくの個人的な意見だけどね。