ストーリーボードと古いXIBの方法
私はiOSの初心者であり、どちらを学ぶのが最善か疑問に思っていました。私はこことSOでいくつかの答えを読みましたが、ストーリーボードを使用すると言う人もいれば、最初にXIBを学ぶと言う人もいます。 XIBを学習することに本当の利点はありますか？ XIBは理解しやすく、ストーリーボードに役立ちますか？
ペン先ではできないストーリーボードでできることがあります。ストーリーボードを使用すると、View Controller間にセグエを作成したり、Table Viewセルをインプレースで設計したりできます。
ペン先でできることは、ストーリーボードではできないことです。ペン先では、File's Ownerプレースホルダーへの参照を作成できます。複数のトップレベルビューを作成、編集、およびそれらの間の接続を作成できます。 この回答を参照してください なぜそれをしたいのかの例について。外部オブジェクトのプレースホルダーを追加できます（めったに使用されない機能）。
ストーリーボードには、大まかに関連するさまざまなオブジェクトを1つの大きなファイルにまとめるという欠点があります。複数の開発者とプロジェクトに取り組んでいる場合、ストーリーボードを使用している場合は、xibファイルを使用している場合よりもマージの競合が発生する可能性が高くなります。
いつか確実にペン先について学ぶ必要があります。それらから始めるか、ストーリーボードから始めるかは、おそらくあまり重要ではありません。好きなチュートリアルを見つけて、使用するファイルの種類（ペン先または絵コンテ）を操作してください。
両方のアプローチを学ぶことには利点があります。
Xibアプローチの歴史的価値とは別に、xibはモジュール性も提供します。おそらく、コードのライブラリを持っているか、作成した便利なウィジェットを共有したいでしょう。 xibアプローチを取ると、その共有と再利用が促進されます。
また、xibアプローチにより、独自のコードに関して柔軟性を高めることができます。たとえば、iOS 5にはUITableViewとAccessibility/VoiceOverのサポートにバグがあり、-dequeueReusableCellWithIdentifier:は、別途文書化されているにもかかわらずnilを返します（詳細については このブログ投稿 を参照してください）。 xibからTable Viewセルを動的にロードすることで、バグを回避する機能が提供されました。
Storyboardsのテーブルとテーブルセルのサポートは素晴らしく、ほとんどの人がテーブルで行う必要のあるものをサポートしますが、場合によっては線の外側に色を付ける必要があり、多くの異なるセルが必要になる場合があります。あなたのソリューション。
Storyboardの大きな利点の1つは、アプリケーションのGUIフロー全体を表示できることです。ズームアウトすると、すべてが相互接続およびフローする様子を確認できます。 xibsを使用すると、モジュール性は優れていますが、すべてがどのように接続して流れるかを想像するのは困難です。これは自分にとって便利な機能です。また、共有するチームが大きい場合は、アプリの流れを他の人に見せることができます。
どちらのアプローチにも価値があります。両方を知っていると、手元のタスクに最適なツールを選択できます。
2014-10-06の更新-上記を書いて以来、私はより多くのプロジェクトに携わってきました。一部はxibで、一部はストーリーボードを使用できます。
ストーリーボードは非常に成熟しており（現在Xcode 6を使用しています）、ストーリーボードは非常に素晴らしいものです。私は、xibアプローチではもう少し複雑なストーリーボード内でこれほど多くのことができるのが大好きです。いくつかの例：
1つは、UITableViewまたはUICollectionViewを使用して、ストーリーボードでプロトタイプセルを直接操作できる場合です。たくさんの素敵で簡単なセットアップ、ほとんどの重い作業はストーリーボードにあり、コードは少なくて済みます。とてもいいです。 xibアプローチでこれを実行しようとすることは確かに実行可能ですが、それを実現するためにはさらに多くの作業があります。
もう1つは、通常のセグエでUIViewControllersの間をどれだけうまく移行してから、巻き戻しセグエで戻ることができるかです。最小限のコードで、ストーリーボードのすべての場所に。とても便利です。
しかし、ストーリーボードを殺してしまうことの1つは、コラボレーション環境でストーリーボードを使用しようとすることです。うまく統合できません。いくつかの点で、1人以上のチームで作業している場合でもそうではありません。自分でバージョン管理を利用し、自分の個人的なワークフローに適切な分岐およびマージモデルを使用する場合は、別の分岐に持ち込む必要のある分岐で何らかの変更を行う必要がある場合があります。ああ、痛み。私にとって、これはストーリーボードを殺すものです。
時間と仕事が進化するにつれて、私が自分で見つけているのは、ストーリーボードがプロトタイピングに最適だということです。物事を迅速に進める能力は、ストーリーボードの大きな利点です。それらの使用にはかなりの速度があります。しかし、速度にはコストがかかります。あるプロジェクトの「本物の」コードを書くことになると、私はxibsに固執するだけです。なぜなら、それはより多くの作業があるかもしれませんが、より柔軟なルートであり、大規模なチームや時間の経過とともにうまく機能するからです。
2015-04-07の更新過去数か月のプロジェクトによりストーリーボードを使用せざるを得なかったため、さらなる洞察が得られたため、別の更新が行われました。
まず、いくつかのことは何らかのアプローチを義務付けます。たとえば、xibsでサイズクラスを操作する際に、ストーリーボードで同じことを行っていなかったEdgeケースバグがあったようです。そのため、バグの影響を受けた場合、何らかの形で手が強制される可能性があります。もう1つは、ストーリーボードは一般にUIViewControllerレベルで機能することを思い出すことです。したがって、ロードするためにUIViewまたはUICollectionViewCellのような何かをする必要がある場合、それはおそらくxibを使用すると効果的です。
第二に、なぜこれが最初に私に起こらなかったのか分かりませんが、プロジェクト全体に単一のストーリーボードを使用する必要があるnothingがあります！ストーリーボードの性質により、人々はそのように引き寄せられると思いますが、それが義務付けられていることを覚えておく必要があります（私は知っています）。
私がうまくいくとわかったのは、一般に、ストーリーボードごとに各「ビューグループ」にアプローチすることです。つまり、多くの場合、ViewControllersは孤立し、ストーリーボード（またはxib）ごとに1つになる傾向があります。ただし、2つの密接に関連するViewControllerがある状況があり、特にそれらをセグエなどの間に簡単に接続できるため、同じストーリーボードに配置するのが理にかなっています。
複数のストーリーボードの主な利点は？チームで働く。この方法で、フレッドは自分の絵コンテで作業でき、ウィルマは絵コンテで作業できます。マージの問題や作業の調整の強い心配はありません！複数のストーリーボード（および通常、ストーリーボードごとに1つのViewController）を使用することは、複数の開発チームでストーリーボードを使用する際に非常に役立ちました。
Appleはストーリーボードを好むことを望んでおり、私は最近それらをより多く受け入れています。
2015-09-21の更新AppleがリリースしたXcode 7がありますAppleは欠点を克服するために機能するため、ストーリーボードを採用するさらに多くの理由です。
最も重要な改善点は、ストーリーボード参照です。これにより、あるストーリーボードに別のストーリーボードへの参照を作成できます。作成するのは非常に簡単で、今ではクロスストーリーボードのセグエ（入り口と出口の両方）を使用できます。私はこれを既に新しいプロジェクトで数回使用しましたが、それはただの喜びです。
もう1つの改善点は、ストーリーボード内にスタンドアロンUIViewクラスを作成できることです。しかし、この記事を書いている時点では、私はそれと複雑な結果を出しました。単純なケースでも問題ありませんが、「複雑な」ものではうまくいきませんでした。たとえば、UIViewControllerとその中にUITableViewがありました。これは、5つの静的セルを持つ単純なテーブルであるため、ストーリーボードのViewControllerの一部として5つのUITableViewCellsをインスタンス化しました。動作しているように見えましたが、実行時に実際にロードされて表示されるものはありませんでした。 UITableViewCellsをxibに移動し、すべて機能しました。私は何か間違ったことをしていたのか、それが何であるのかわからないので、YMMV。それでも、ちょっとした癖があっても、やがてAppleがそれらを解決し、ストーリーボードに対する別の障壁がなくなると確信しています。そのようなサポートが必要な場合は、試してみて、それがあなたにどのように役立つかを見てください。
ストーリーボードはますます優れたものになりつつあります。