StoryBoardを使わないことにした理由

iOS Swift StoryBoard Xcode

iOSアプリ開発において、StoryBoardを使う派ですか？使わない派ですか？

いろいろ試してみた結果、とあるプロジェクトでStoryBoardを使わないことにしました。
その理由を書きます。


1. コードとStoryBoardの関係がわかりにくい

StoryBoardを使うといっても普通はコードを書かないわけにはいかないので、StoryBoardを使う＝StoryBoardを使うしコードも書く、ということになります。
つまり、StoryBoardとコードの両方を理解して初めて全体を把握できるということです。
StoryBoardでこれを定義すると、コードでいうところのどの処理までできるのか、ということがなかなか直感的にはわからなくて、StoryBoardとコードの間を脳内で埋める作業？が私には面倒でした。
これは、最終的にコードで理解したいかどうか次第で、人によって受け方が違ってくると思います。
私は、変更内容はDiffで明確にならないと気持ち悪い派なのです。

2. ちょっと複雑な構成になるとStoryBoardの難易度が高い

StoryBoardはとても簡単に画面や遷移を定義できますが、ちょっと複雑な構成になってくると、その難易度が高くなる印象がありました。
簡単なプロトタイプなどの作成ではStoryBoardのほうが速いのですが、複雑になるとStoryBoardでどう定義すればよいのか調べるのに結構時間がかかりました。
単にStoryBoardを高度に使いこなせていないだけかもしれませんが。。

3. まれにStoryBoard上の見た目とビルドしたアプリで差異が出ることがある

UITableCell絡みで、ビルドするとズレて表示されてしまうことがありました。
StoryBoard上で同じ場所に再定義（移動して同じ場所に戻す）するとズレが解消するのですが、開発を進めているとまたいつの間にかズレでしまうという。。
私の使い方が悪いのかわかりませんが、こういうのがまた気持ち悪さにつながってしまうんですよね。。

4. コードに慣れてくるとStoryBoardのありがたさが半減する

コード（Swift）に慣れてくると、StoryBoardとさほど変わらない速さで（というと大げさですが）開発を進めることができるようになったので、少なくとも速さの面ではありがたみが薄れました。



とはいえ、一方でStoryBoardの良さも実感できました。例えば、コードが少なくてスッキリ、画面遷移が見たままでわかる、分業しやすい、新規メンバーの理解の助けになる、など。適材適所に使い分ける必要がありそうですね。