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