ストーリーボードを使用する場合とXIBを使用する場合
回答:
XIBを多用し、ストーリーボードを使用して2つのプロジェクトを完了しました。私の学びは：
- ストーリーボードは、少数から中程度の数の画面と、ビュー間のナビゲーションが比較的簡単なアプリに適しています。
- 多数のビューとそれらの間の多数のクロスナビゲーションがある場合、ストーリーボードビューは混乱し、クリーンに保つには多くの作業が必要になります。
- 複数の開発者がいる大規模なプロジェクトの場合、UIに単一のファイルがあり、簡単に並行して作業できないため、ストーリーボードは使用しません。
- 大きなアプリを複数のストーリーボードファイルに分割することは価値があるかもしれませんが、私はそれを試していません。この回答は、ストーリーボード間でセグエを実行する方法を示しています。
- それでもXIBが必要です。両方のストーリーボードプロジェクトで、カスタムテーブルセルにXIBを使用する必要がありました。
ストーリーボードはUI実装の正しい方向への一歩であり、Appleが将来のiOSバージョンでそれらを拡張することを願っています。ただし、「単一ファイル」の問題を解決する必要があります。解決しないと、大規模なプロジェクトにとって魅力的ではありません。
小さなサイズのアプリを起動して、iOS5のみの互換性を提供できるのであれば、ストーリーボードを使用します。他のすべてのケースでは、XIBを使用します。
2016年1月12日更新：2016年ですが、UIをストーリーボードではなくコードでレイアウトすることを好みます。そうは言っても、ストーリーボードは長い道のりを歩んできました。この投稿から、2016年には適用されなくなったすべてのポイントを削除しました。
2015年4月24日更新：として興味深いことにAppleはさえ彼らの最近オープンソースResearchKitでストーリーボードを使用していないピーター・スタインバーガーが気づいた（小見出し「Interface Builderの」下）。
アップデート6/10/2014：予想通り、アップルはストーリーボードとXcodeを改善し続けています。iOS 7以前に適用されていたいくつかのポイントは、iOS 8には適用されなくなりました（そのようにマークされています）。ストーリーボードは、本質的にまだ欠陥を持っていながら、だから、私はから私のアドバイスを修正使用していないにそれは理にかなっている選択的に使用。
iOS 9が出た今でも、私は助言します に対してストーリーボードを使用するかどうかを決定する際は注意が必要です。ここに私の理由があります：
ストーリーボードは、コンパイル時ではなく実行時に失敗します。セグエ名にタイプミスがあるか、ストーリーボードの接続に誤りがありますか？実行時に爆発します。ストーリーボードにもう存在しないカスタムUIViewControllerサブクラスを使用していますか？実行時に爆発します。このようなことをコードで行うと、コンパイル時の早い段階で問題が発生します。更新：私の新しいツールStoryboardLintは、この問題をほぼ解決します。
ストーリーボードはすぐに混乱する：プロジェクトが成長するにつれて、ストーリーボードの操作がますます難しくなります。また、複数のView Controllerが他の複数のView Controllerに対して複数のセグエを持つ場合、ストーリーボードはすぐにスパゲッティのボウルのように見え始め、ズームイン、ズームアウト、スクロールして、目的のView Controllerを見つけることができます。セグエがどこを指しているのかを見つけるために。アップデート：で説明したように、この問題は、ほとんどがあなたのストーリーボードは、複数のストーリーボードに分割することで、最大解決することができるPilkyによって、この記事とロバート・ブラウンこの記事。
ストーリーボードはチームでの作業を難しくします。通常、プロジェクトには大きなストーリーボードファイルが1つしかないので、複数の開発者が定期的にその1つのファイルに変更を加えると、頭痛の種になる可能性があります。変更をマージし、競合を解決する必要があります。XcodeはストーリーボードXMLファイルを生成しますが、編集はもちろん、人間が読む必要があることを念頭に置いて設計されていません。
ストーリーボードは、コードレビューを困難またはほぼ不可能にします。ピアコードレビューは、チームで行うのに最適です。ただし、ストーリーボードに変更を加える場合、別の開発者がこれらの変更を確認することはほとんど不可能です。取得できるのは、巨大なXMLファイルの差分だけです。実際に何が変更されたか、それらの変更が正しいかどうか、または何かが壊れているかどうかを解読することは、本当に難しいことです。
ストーリーボードはコードの再利用を妨げる：私のiOSプロジェクトでは、通常、すべての色とフォント、マージンとインセットを含むクラスを作成し、アプリ全体で使用して一貫したルックアンドフィールを提供します。アプリ全体でこれらの値のいずれかを調整します。ストーリーボードでそのような値を設定した場合、それらを複製し、それらを変更したいときにすべての出現箇所を見つける必要があります。ストーリーボードには検索や置換がないため、見逃す可能性が高くなります。
ストーリーボードには一定のコンテキストスイッチが必要です。ストーリーボードよりもコードの方が作業とナビゲーションがはるかに高速です。アプリでストーリーボードを使用する場合、常にコンテキストを切り替えます。「ああ、このテーブルビューセルをタップして、別のビューコントローラーを読み込む必要があります。ここで、ストーリーボードを開いて、適切なビューコントローラーを見つけ、新しいセグエを作成する必要があります。他のビューコントローラー（これも検索する必要があります）に名前を付け、その名前を思い出し（ストーリーボードでは定数または変数を使用できません）、コードに戻って、名前を間違って入力しないことを望みます。 prepareForSegueメソッドのセグエです。ここにある3行のコードをここに入力する方法を教えてください！」いいえ、それは楽しいことではありません。コードとストーリーボードの間（およびキーボードとマウスの間）を切り替えると、古くなり、遅くなります。
ストーリーボードをリファクタリングするのは難しい：コードをリファクタリングするときは、ストーリーボードが期待するものとまだ一致していることを確認する必要があります。ストーリーボード内で物事を移動するとき、それがまだコードで機能する場合にのみ実行時にわかります。2つの世界を同期させる必要があるように感じます。それはもろく感じ、謙虚な意見の変化を思いとどまらせます。
ストーリーボードは柔軟性が低くなります。コードでは、基本的に何でも好きなことができます！ストーリーボードを使用すると、コードで実行できることのサブセットに制限されます。特にアニメーションやトランジションで高度なことをしたい場合は、「ストーリーボードと戦う」ことで機能します。
ストーリーボードは、あなたが特別なビューコントローラの種類を変更できません：あなたは、変更したい
UITableViewControllerにUICollectionViewController？または平野にUIViewController？ストーリーボードではできません。古いView Controllerを削除して新しいView Controllerを作成し、すべてのセグエを再接続する必要があります。このようなコードの変更を行う方がはるかに簡単です。ストーリーボードは、プロジェクトに2つの追加の責任を追加します。（1）ストーリーボードXMLを生成するストーリーボードエディターツール、および（2）XMLを解析してそこからUIおよびコントローラーオブジェクトを作成するランタイムコンポーネント。どちらの部分にも、修正できないバグがある可能性があります。
ストーリーボードでは、サブビューをaに追加できません
UIImageView。理由は誰が知っていますか。ストーリーボードでは、個々のビュー（-コントローラー）の自動レイアウトを有効にすることはできません。ストーリーボードの自動レイアウトオプションをオン/オフにすると、ストーリーボード内のすべてのコントローラーに変更が適用されます。（この点についてはSavaMazăreに感謝します！）
ストーリーボードには下位互換性が損なわれるリスクが高くなります。Xcodeはストーリーボードのファイル形式を変更する場合があり、今日作成したストーリーボードファイルを数年後または数か月後まで開くことができることを保証するものではありません。（この点については、 thoughtadvancesに感謝します。元のコメントを参照してください）
ストーリーボードは、コードをより複雑にする可能性があります。コードでビューコントローラーを作成する場合、カスタム
initメソッドなどを作成できますinitWithCustomer:。そうすることcustomerで、ビューコントローラーの内部を不変にして、customerオブジェクトなしでこのビューコントローラーを作成できないようにすることができます。ストーリーボードを使用している場合、これは不可能です。prepareForSegue:sender:メソッドが呼び出されるのを待つ必要があり、その後customer、ビューコントローラーでプロパティを設定する必要があります。つまり、このプロパティを変更可能にし、customerオブジェクトなしでビューコントローラーを作成できるようにする必要があります。 。私の経験では、これはコードを非常に複雑にし、アプリのフローを推論することを難しくします。2016年9月9日更新：Chris Dzombakがこの問題について素晴らしい記事を書いています。それはマクドナルドです：スティーブ・ジョブズのマイクロソフトについての言葉でそれを言うために：それはマクドナルド（ビデオ）です！
これらが、ストーリーボードでの作業が本当に嫌いな私の理由です。これらの理由のいくつかは、XIBにも適用されます。私が取り組んできたストーリーボードベースのプロジェクトでは、節約した時間よりもはるかに多くの時間を費やしていて、物事をより簡単にするのではなく、より複雑にしています。
コードでUIとアプリケーションフローを作成すると、何が起こっているかをより制御できるようになり、デバッグが容易になり、ミスを早期に発見しやすくなり、変更を他の開発者に説明しやすくなります。 iPhoneとiPadをサポートする方が簡単です。
ただし、すべてのUIをコードでレイアウトすることが、すべてのプロジェクトで万能のソリューションであるとは限らないことに同意します。iPadのUIが特定の場所でiPhoneのUIと大きく異なる場合、それらの領域だけにXIBを作成することは理にかなっています。
上で概説した問題の多くはAppleによって修正される可能性があり、私はそれが彼らがすることであることを願っています。
ちょうど私の2セント。
更新：Xcode 5では、アップルはストーリーボードなしでプロジェクトを作成するオプションを取り除きました。Xcode 4のテンプレート（Storyboard-opt-outオプション付き）をXcode 5に移植する小さなスクリプトを作成しました：https : //github.com/jfahrenkrug/Xcode4templates
ストーリーボードは、開発者がアプリケーションとアプリケーションのフローを視覚化できるように作成されました。それはたくさんのxibを持っているようにたくさんですが、単一のファイルにあります。
これと同様の質問があります。.xibファイルと.storyboardの違いは何ですか？。
.xibsでできるように、必要に応じて動的に変化するコードを介してカスタム遷移を作成することもできます。
長所：
- コードを記述しなくても、アプリケーションのフローをモックアップできます。
- 画面とアプリケーションフローの間の遷移がはるかに見やすくなります。
- ストーリーボードで必要に応じて.xibsを使用することもできます。
短所：
- iOS 5以降でのみ機能します。iOS4では動作しません。
- 非常にビュー集約型のアプリケーションを使用している場合、簡単に乱雑になる可能性があります。
どちらを使用するかは、実際に正しい/間違っているわけではありません。それは、単に好みの問題であり、使用したいiOSのバージョンです。
私はちょうど状態になる4つの単純な理由から、あなたがなぜなければならないなど、製品の所有者、プロダクトマネージャー、UXデザイナーのチームで仕事に特にあなたが持っている生産的な環境でのストーリーボードを使用し、
- アップルはストーリーボードの操作を大幅に改善しました。そして、彼らはあなたが彼らと一緒に働くことを勧めます。つまり、既存のプロジェクトをアップデートで壊すことはなく、ストーリーボードが新しいXCode / iOSバージョンの将来の証明になることを保証します。
- 作成フェーズ中であっても、製品の所有者と管理者の目に見える結果が増えると、時間を短縮できます。ストーリーボード自体を画面フロー図として使用して、会議で話し合うこともできます。
- アプリが完成した後でも（そして一般的には、アプリのライフサイクルが始まります）–将来的には、小さな調整を適用する方が速くて簡単になります。そして、これらは同時にレイアウトの複数の側面を非常によく変更する可能性があり、おそらくWYSIWYGの方法で確認したいでしょう。代わりの方法は、コードでUIの変更を手書きで書き込み、IDEとシミュレーターを交互に切り替えてテストし、コンパイルとビルドを待機することです。
- 非開発者は、ストーリーボードにレイアウトを設定し、開発者に必要なフック（IBOutletsおよびIBActions）を作成するように教えることができます。開発者がロジックに集中でき、UXデザイナーがコードをまったく記述しなくても、変更を視覚的に適用できるため、これは非常に大きなプラスです。
ヨハネスはすでに彼の答えに実行可能なものすべてをおそらくリストしているので、私はどんなCONSも書きません。そして、それらのほとんどは確かに実行可能ではありません。特に、XCode6の大幅な改善はありません。
私はあなたの質問に正しい答えがあるとは思いません、それは単に個人的な経験とあなたがより快適に感じるものの問題です。
私の意見では、ストーリーボードは素晴らしいものです。確かに、実行時にアプリが不思議なほどクラッシュする理由を見つけるのは非常に困難ですが、しばらくして経験を積むと、どこかに欠けているIBOutletに常に関連していることに気づき、簡単に修正できるようになります。
唯一の本当の問題は、ストーリーボードを使用したバージョン管理下のチームで作業することです。開発の初期段階では、それは本当の混乱になる可能性があります。しかし、その最初の段階の後、ストーリーボードを完全に変更するUIの更新は非常にまれであり、ほとんどの場合、XMLの最後の部分で競合が発生します。これは、通常、ストーリーボードを再度開いたときに自動修正されるセグエ参照です。 。私たちのチームワークでは、大量のビューコードを備えた重いビューコントローラーではなく、これに対処することを選びました。
自動レイアウトに関する多くのコメントを読みました。XCode5でそれは本当に改善されました、それは自動回転レイアウトのためにも本当に良いです。場合によっては、コードで何かをしなければならないことがありますが、編集する必要がある制約を単純に解除して、その時点でコードで必要なことを行うことができます。それらをアニメーション化します。
また、ストーリーボードが嫌いな人のほとんどは、カスタムマニュアルセグエの力を完全に理解しようとはしなかったと思います。この方法では、ある方法から別の方法に（また、いくつかのトリック）全体を完全に再ロードする代わりに、ビューのコンテンツを更新するだけで、以前にロードされたビューコントローラーを再利用します。最後に、コードと同じことを実際に行うことができますが、ストーリーボードに関する懸念をよりうまく分離できると思いますが、多くの点で機能（フォント、色の背景としての画像、ecc ... ）。
StoryBoardまたはXIBをアプリで使用していませんが、プログラムですべてを作成しています。
∆メリット：
√の複雑な種類のUIまたは遷移アニメーションを作成できますUIView。
√すべてのiOSバージョンをサポートします。<iOS 5について心配する必要はありません。
√*アプリは、コード内のすべてのiPhone / iPod / iPadデバイスをサポートします。
√常に機能するコードを知っているので、常に更新されます。
√*起動した（新しい）デバイスで動作します–コードを変更する必要はありません。
√すべてはあなた次第です。特定の場所で何かを変更したい–ストーリーボードやxibを調べる必要はありません。特定のクラスで検索してください。
√最後ですが、リストではありません–プログラムですべてを管理する方法を忘れないでください。誰よりも深いコントロールを知っているので、これは最良のことです。
私はこれに長けているので、SBまたはXIBを使用しないことで問題を見つけることはありません。
* UIKitのオブジェクトフレームを画面サイズに応じて設定した場合。
PSまだこの作業を行っていない場合–困難に直面する可能性があります（または退屈に感じるかもしれません）が、これに慣れると–それは本当にあなたのためのキャンディーです。
ストーリーボードのパフォーマンスを気にする場合は、WWDC 2015セッション407をご覧ください。
ビルドタイム
インターフェイスビルダーがストーリーボードをコンパイルするとき、最初に2つのことを行います。それは、アプリケーションのパフォーマンスを最大化することです。次に、作成されるnibファイルの数も最小化します。
ビューと一連のサブビューを持つビューコントローラー、インターフェイスビルダーがある場合、ビルド時間はビューコントローラーのnibファイルを作成し、ビューのnibファイルを作成します。
ビューコントローラーとビューの両方に個別のnibファイルを用意することで、ビューの階層をオンデマンドで読み込むことができます。
実行時間
UIストーリーボードAPIを使用してストーリーボードインスタンスを割り当てる場合、最初にメモリを割り当てるのは、UIストーリーボードインスタンス自体だけです。
ビューコントローラーはまだビューがありません。
初期ビューコントローラーをインスタンス化すると、その初期ビューコントローラーのnibが読み込まれますが、誰かが実際に要求するまで、ビュー階層はまだ読み込まれていません。
私は適度なサイズのプロジェクト（ストーリーボード用語で20シーン以上）に取り組んでおり、多くの制限に直面し、ドキュメントやgoogle検索に繰り返しアクセスしなければなりません。
UIはすべて1つのファイルにあります。複数のストーリーボードを作成しても、各ストーリーボードには多くのシーン/画面があります。これは中規模のチームの問題です。
次に、他のコンテナーコントローラーなどを埋め込むカスタムコンテナーコントローラーではうまく機能しません。タブ付きアプリケーションでMFSlideMenuを使用しており、シーンにはテーブルがあります。これは、ストーリーボードでは不可能です。私は何日も過ごしてきたので、完全に制御できるXIBの方法を使用しました。
IDEでは、ズームアウト状態のコントロールを選択することはできません。したがって、大規模なプロジェクトでは、ズームアウトは主に高レベルのビューを得るためのものであり、それ以上のものはありません。
チームサイズが小さい小規模なアプリケーションにはストーリーボードを使用し、中規模のチーム/プロジェクトにはXIBアプローチを使用します。