ソフトウェア開発においてプログラムの分離は，スマートフォンアプリが登場する以前から重要なテーマの1つで，プログラムの見通しを良くしたり，再利用性を高める目的でしばしば語られます。デザインパターンとして知られるMVC（Model View Controller）やMVVM（Model View ViewModel）が有名ですが，ここではiOSアプリ開発における画面レイアウトとプログラムの分離のお話です。

iOSアプリ開発でのデザインの作り込み

iOSアプリでもUI（ユーザインタフェース）のデザイン性は非常に重要です。AppStoreで高い評価を受けているアプリで，ボタンやナビゲーションバーが標準の色・形のままのアプリや，画面レイアウトが雑な作りになっているアプリは皆無と言っていいでしょう。しかし，デザインをしっかり作り込むには，デザイナーさんとの共同作業が欠かせません。デザイナーさんが作った画像素材をボタンやビューに適用したり，文字の色やサイズをデザイン案に合わせていきます。そして，iOSアプリ開発に占めるデザイン関連の作業比率はますます高くなっています。

デザイン要素

Apple社が公式に提供している開発ツールである「Xcode」でiOSアプリを作成する場合，プログラムをSwift言語なら.swiftファイルに，Objective-C言語なら.hや.mファイルに書きます。かたやデザイン要素はStoryboardファイル（Xcode 4.2で導入された機能）やxibファイルで設定します。さらに，Storyboardやxibファイルで設定する内容は，すべてプログラム側でも実現可能なのです。

「ボタンを配置する」「⁠ナビゲーションバーの色を変更する」などの画面レイアウトやデザインに関する各操作には，それらと同じことを実現できるクラスとメソッドが用意されており，極端な話，Storyboard，xibファイルをまったく使わなくても，iOSアプリを開発することもできるのです。

iOSアプリ開発の系譜

少し歴史を振り返ると，Xcodeがバージョン3系のころは，Swift言語やStoryboardは存在せず，Objective-Cとxibファイルの組み合わせしかありませんでした。画面レイアウトのためのxibファイルはInterface Builderという別の開発ツールで作成していました。

Xcodeがバージョン4になってから，Interface BuilderはXcodeに取り込まれる形で統合されました。しかし，現在でもAppleのドキュメントには「Interface Builderによる……」という文言がたびたび出てきたりします。Storyboardファイルを使う場面のほうが多いですが，xibファイルも引き続き使えます。そして，Xcodeがバージョン6になったときにSwiftが採用され，現在に至ります。

Storyboardでの開発とは

xibファイルとStoryboardファイルの大きな違いは，画面遷移の情報を内包するかどうかです。xibファイルは，1画面分の画面レイアウト，または画面の一部のビューのみを表現するのに用いられますが，Storyboardには複数の画面レイアウトと，それに加えて，画面と画面をどのように繋ぐかの画面遷移情報も含められます。その名のとおり「絵コンテ」のようなものです。絵コンテや画面遷移図を描くような感覚で，アプリを作っていくことができます。

アプリの全画面を1つのStoryboardファイルにすべて押し込むこともできますし，いくつかのStoryboardファイルに分割することもできます。また，特定のビューをxibファイルで作成し，Storyboardと組み合わせて使うこともできます。

xibもStoryboardも実態はXMLファイルです。つまりGitなどのバージョン管理システムの管理下に置くことができます。巨大なStoryboardファイルを作ってしまうと，他の開発者とコンフリクト（不整合によって衝突）する頻度が上がるなどの注意点はいくつかあります。見やすさの観点からも，通常は3～5画面ごとにStoryboardファイルを1つ，または1画面＝1Storyboardファイルに分割して作業します。

デザイナーから見たStoryboard

このようにプログラムファイルとは別に，画面レイアウト用のファイルが用意されているXcodeですが，難点もあります。

開発現場では画面レイアウトはUIデザイナーさんが担当することが多いです。私個人としては，デザイナーの人でも簡単に使えるぐらいStoryboardが扱いやすいものであればいいのにと思いますが，現実はそこまではやさしくありません。

まず，Interface BuilderがXcodeに統合されてしまったが故に「開発者用ツール」としての印象が強くなり，デザイナーさんにはよりとっつきにくい印象になったこと。また，画面をレイアウトするときの操作性も，やはりAdobe系のツールなどと比較するとまだまだ貧弱です。

例を挙げると，レイヤー機能やロック機能がないので，画面内のパーツが増えてくると画面内でパーツを移動すること自体にストレスを感じる場面が多々あります（Xcode 8になって，ようやく表示領域の拡大縮小が簡単になりました……⁠）⁠。

また，これは致し方のないことですが，どうしてもStoryboardファイル側にもプログラムの要素が顔を出してきます。アプリの画面は動的な画面がほとんどです。ユーザの操作を画面で受け取り，それをプログラムで処理し，画面表示を変更する，というアプリ動作の基本サイクルを実現するため，Storyboardファイルにプログラムとの結合点（インタフェース）を設ける必要があります。このため，デザイナーさんには見慣れない（かつ，あまり見たくない）プログラムの断片がStoryboard側に出現します。

具体的には，プログラムのクラス名やメソッド名，変数名がStoryboardの作業画面に出てきて，これらの名前と画面レイアウト用のパーツを関連付ける作業が発生します。この作業自体は，さほど難易度が高くないので，デザイナーさんでも少しの学習コストで習得できますが，Storyboardは純粋にデザイン要素だけで構成されるファイルではありません。プログラムとUIの橋渡しをする役目を担っています。

Storyboardを勧める理由

Xcodeは画面レイアウトツールとしてはまだまだ改善の余地があり，デザイナーさんとの分業にも工夫すべきポイントがあることは事実ですし，前述したようにStoryboardやxibファイルをまったく使わなくてもアプリを開発できるため，巷には画面レイアウトの実装もすべてプログラムで行うことを好む「Storyboardは使わない派」のプログラマーさんも結構います。しかし，私個人としては，画面レイアウト関連の作業は可能な限りStoryboard上で行うようにしています。それは画面レイアウトとプログラムの関心事はできるだけ分離したいからです。「⁠レイアウトの配置を変更するときにはStoryboardファイルを開く⁠」⁠，「⁠ビジネスロジックを実装するときにはプログラムファイルを開く」と頭を切り替えたいのです。

また，プログラムで表現された画面レイアウトは，非常に可読性が低いです。パッと見てどのようなレイアウトが表現されているのか把握できません。自分で書いたプログラムならまだしも，他人の書いたプログラムでは，正直，ビルドしてアプリを実行してみないと，どのような画面を持ったアプリなのか皆目見当がつきません。その点，Storyboard上で構成された画面レイアウトはXcode上で見るだけで，一目瞭然です。

また，最近では，異なる画面サイズ・解像度のハードウェアに対応するためにはAdaptiveな（適応性のある）画面レイアウト構成が必須で，それにもStoryboardの機能を素直に使ったほうが開発コストを小さくできます。また，UIデザイナーさんからの要望は，しばしばデザイン的にシビアになることがあります。そのようなピクセル単位の微調整の要望に応えるための細かな調整をプログラムベースで行っていると，かなり開発コストが高くなります。

ビギナープログラマーにとってのStoryboard

プログラミングビギナーの方には，ぜひStoryboardを使ってアプリ開発にチャレンジしてみてほしいです。Storyboardなしで開発する場合と比べて，プログラムを書く量を格段に少なくすることができます。Storyboardにパーツを配置して，プログラムを少しだけ書いて，マウスでパーツとプログラムをちょいちょいと繋げるだけで，アプリが動き出すのはとても楽しいものです。そのままの流れで，Adaptiveな画面レイアウトに習熟できるのもメリットだと思います。

ただ，Storyboard上だと直感的にレイアウト作業ができるとは言っても，汎用的な画面レイアウトを提供するAutoLayout機能を使い出すあたりから壁にぶつかることが多くなると思います。しかし，AutoLayout機能の中でもよく使うものはいくつかに限られます。それらのメインの機能を使いこなすだけでも，大抵のレイアウトに対応できます。また，iOS 9から導入されたスタックビューなども併用すれば，より簡単に画面レイアウトを整えることができます。ぜひ，ご自身で試してください！