Are there any guidelines on when to use storyboards in an iOS project and when to use XIBs? what are the pros and cons of each and what situations do they each suit?
私の知る限り、動的な UI 要素 (マップ ピンなど) によってビュー コントローラーがプッシュされている場合、ストーリーボード セグエを使用するのはそれほどクリーンではありません。
ベストアンサー1
2016年1月12日更新: 2016 年になりましたが、私は今でもストーリーボードではなくコードで UI をレイアウトすることを好みます。そうは言っても、ストーリーボードは大きく進歩しました。2016 年にはもはや当てはまらないポイントはすべてこの投稿から削除しました。
2015年4月24日更新: 興味深いことに、Appleは最近オープンソース化したResearchKitでもStoryboardsを使用していません。ピーター・スタインバーガーは気づいた(「Interface Builder」というサブ見出しの下)。
2014年6月10日更新: 予想通り、AppleはStoryboardとXcodeを改良し続けています。iOS 7以前に適用されていたポイントのいくつかはiOS 8には適用されません（そして、そのようにマークされています）。そのため、Storyboardには本質的にまだ欠陥がありますが、私はアドバイスを修正します。使用しないでくださいに意味のあるところで選択的に使用する。
iOS 9がリリースされた今でも、私は
に対して
ストーリーボードを使用するかどうかを決める際には注意が必要です。理由は次のとおりです。
ストーリーボードはコンパイル時ではなく実行時に失敗する: セグエ名にタイプミスがあったり、ストーリーボードで間違って接続したりしていませんか? 実行時にエラーが発生します。ストーリーボードに存在しないカスタム UIViewController サブクラスを使用していますか? 実行時にエラーが発生します。コードでこのようなことを行うと、コンパイル時に早い段階で検出されます。アップデート: 私の新しいツールストーリーボードリントこの問題は大抵解決します。
ストーリーボードはすぐに混乱する: プロジェクトが大きくなるにつれて、ストーリーボードの操作はますます難しくなります。また、複数のビュー コントローラーに複数の他のビュー コントローラーへの複数の segue がある場合、ストーリーボードはすぐにスパゲッティのボウルのようになり、探しているビュー コントローラーを見つけて、どの segue がどこを指しているかを確認するために、ズームイン、ズームアウト、スクロールを繰り返すことになります。アップデート: この問題は、ストーリーボードを複数のストーリーボードに分割することで解決できます。この記事はPilkyによるものですそしてロバート・ブラウンによるこの記事。
ストーリーボードはチームでの作業を難しくする: 通常、プロジェクトには 1 つの巨大なストーリーボード ファイルしかないため、複数の開発者がその 1 つのファイルを定期的に変更するのは面倒な作業です。変更をマージし、競合を解決する必要があります。競合が発生した場合、解決方法がわかりにくいです。Xcode はストーリーボード XML ファイルを生成しますが、実際には人間が読み取ったり、ましてや編集したりすることを念頭に置いて設計されたものではありません。
ストーリーボードはコードレビューを困難にしたり、ほぼ不可能にしたりする: ピアコードレビューはチームで行うと非常に便利です。しかし、ストーリーボードに変更を加えた場合、別の開発者と一緒にこれらの変更をレビューすることはほぼ不可能です。取得できるのは巨大な XML ファイルの diff だけです。実際に何が変更されたのか、その変更が正しいのか、それとも何かが壊れているのかを解読するのは非常に困難です。
ストーリーボードはコードの再利用を妨げる: iOS プロジェクトでは、通常、一貫した外観と操作感を実現するために、アプリ全体で使用するすべての色、フォント、余白、インセットを含むクラスを作成します。アプリ全体でこれらの値を調整する必要がある場合は、1 行の変更で済みます。ストーリーボードでこのような値を設定すると、値が重複し、変更するときにすべての出現箇所を探す必要があります。ストーリーボードには検索と置換がないため、見落とす可能性が高くなります。
ストーリーボードでは、常にコンテキストの切り替えが必要です: ストーリーボードよりもコードの方が作業やナビゲーションがはるかに高速であることに気づきました。アプリでストーリーボードを使用すると、コンテキストを頻繁に切り替えることになります。「ああ、このテーブル ビュー セルをタップして別のビュー コントローラーをロードしたい。ストーリーボードを開いて適切なビュー コントローラーを見つけ、別のビュー コントローラーへの新しいセグエを作成し (これも見つける必要があります)、セグエに名前を付け、その名前を覚えておき (ストーリーボードでは定数や変数を使用できません)、コードに戻って、prepareForSegue メソッドのセグエの名前を誤って入力しないことを祈ります。今いる場所で、その 3 行のコードを入力できればどんなにいいだろう!」いいえ、楽しいことではありません。コードとストーリーボード (およびキーボードとマウス) を切り替えるのはすぐに飽きてしまい、作業が遅くなります。
ストーリーボードはリファクタリングが難しい: コードをリファクタリングするときは、それがストーリーボードの期待どおりに機能していることを確認する必要があります。ストーリーボード内で物事を移動した場合、それがコードで機能するかどうかは実行時にのみわかります。2 つの世界を同期させておく必要があるように感じます。私の意見では、それは不安定で、変更を妨げます。
ストーリーボードは柔軟性が低い: コードでは、基本的に何でもできます。ストーリーボードでは、コードで実行できることのサブセットに制限されます。特に、アニメーションやトランジションを使用して高度な操作を実行したい場合は、ストーリーボードを機能させるために「ストーリーボードと格闘」することになります。
ストーリーボードでは特別なビューコントローラの種類を変更できない
UITableViewController:を に変更しますUICollectionViewControllerか? それともプレーンに変更しますかUIViewController? ストーリーボードでは不可能です。古いビュー コントローラを削除して新しいものを作成し、すべてのセグエを再接続する必要があります。コードでこのような変更を行う方がはるかに簡単です。ストーリーボードはプロジェクトに2つの追加負担を加える: (1) ストーリーボード XML を生成するストーリーボード エディター ツールと (2) XML を解析してそこから UI およびコントローラー オブジェクトを作成するランタイム コンポーネント。どちらの部分にも、修正できないバグが存在する可能性があります。
ストーリーボードではサブビューを追加することはできません。
UIImageView: 理由は誰にも分からない。ストーリーボードでは、個々のビュー（コントローラー）に対して自動レイアウトを有効にすることはできません。: ストーリーボードで自動レイアウト オプションをオン/オフにすると、その変更はストーリーボード内のすべてのコントローラーに適用されます。(この点については Sava Mazăre に感謝します!)
ストーリーボードは下位互換性を損なうリスクが高い: Xcode は Storyboard ファイル形式を変更することがあり、今日作成した Storyboard ファイルを数年後、あるいは数か月後に開けるかどうかは保証されません。(この点については thoughtadvances に感謝します。)元のコメントを見る）
ストーリーボードはコードを複雑にする可能性がある: コードでビュー コントローラを作成するときに、カスタム
initメソッドを作成できます (例: )initWithCustomer:。こうすることで、customerビュー コントローラの内部を不変にし、このビュー コントローラがオブジェクトなしでは作成できないようにすることができます。これは、ストーリーボードを使用する場合は不可能です。メソッドが呼び出されるのcustomerを待ってから、ビュー コントローラのプロパティを設定する必要があります。つまり、このプロパティを可変にし、ビュー コントローラがオブジェクトなしで作成できるようにする必要があります。私の経験では、これによりコードが非常に複雑になり、アプリのフローを理解するのが難しくなります。prepareForSegue:sender:customercustomer2016年9月9日更新: クリス・ゾンバックはこの問題に関する素晴らしい記事。マクドナルドです: スティーブ・ジョブズがマイクロソフトについて語った言葉で言うと:それはマクドナルドです（ビデオ）！
これらは、私がストーリーボードでの作業を本当に好まない理由です。これらの理由のいくつかは、XIB にも当てはまります。私が取り組んだストーリーボード ベースのプロジェクトでは、ストーリーボードによって節約できた時間よりも、かかった時間の方がはるかに長く、作業が簡単になるどころか、より複雑になってしまいました。
UI とアプリケーション フローをコードで作成すると、何が起こっているかをより細かく制御でき、デバッグが容易になり、早い段階で間違いを見つけやすくなり、他の開発者に変更を説明しやすくなり、iPhone と iPad をサポートしやすくなります。
しかし、レイアウトについては同意しますすべてのUIコード内の XIB は、すべてのプロジェクトに当てはまる万能のソリューションではない可能性があります。iPad UI が特定の場所で iPhone UI と大きく異なる場合は、その領域専用の XIB を作成するのが合理的です。
上で概説した問題の多くは Apple によって解決される可能性があり、私は Apple がそうしてくれることを願っています。
あくまでも私の意見です。
アップデート: Xcode 5 では、Apple は Storyboard なしでプロジェクトを作成するオプションを削除しました。私は、Xcode 4 のテンプレート (Storyboard をオプトアウトするオプション付き) を Xcode 5 に移植する小さなスクリプトを作成しました。https://github.com/jfahrenkrug/Xcode4templates