StoryboardやXibは使わない方が良いかも?

まだ、もや〜としているのですが、規模がある程度まで大きいものや長期的に開発を続けるものには、StoryboardやXibは使わない方が良いかもと思ってきました。
今まで、大規模なものでも使ってきましたが、長期的に開発を続けていると、途中でXcodeのバージョンを移行することが多くあります。特にMacのアプリの場合、動作環境は数年前のOSでもサポートしています。開発環境は最新OSでやっていても、ユーザーの環境は古いという組み合わせはごく普通のことです。すると、不具合が起きたときに、3個くらい前のOSでのみ再現するということが往々にして発生します。そんなとき、その環境を用意して、いざデバッグしようと思うと、Xcodeのバージョンも古くしないと出来ないという状態になります。コード自体は古いバージョンでもビルド出来るのですが、XibやStoryboardのフォーマットバージョンに阻まれて、ビルド失敗になることがあります。
もちろん、Xcode上でXibのフォーマットバージョンを下げることは出来ますが、数が多いと大変です。また、Xcodeのメジャーバージョンを2つくらい下げるときには、次のように多段階に下げる必要があります。
(1) 最新版で下げられる所まで下げる
(2) 下げたところを開けるOSとXcodeを別に用意して、更にターゲットの所まで下げる
(3) ターゲットで開発
そして、ターゲットの古いバージョンで修正が終わって、Gitにコミットするときには、コードだけをコミットします。Xibはビルドのためだけに下げているので、コミットしません。しかし、疲れていると、間違えてコミットしてしまうこともあります。それが原因で別の問題がとなると目も当てられません。
この操作ミスの可能性も無くしつつ、Xcodeのバージョン横断も出来るようにと考えていくと、XibやStoryboardを使わずにコードだけで作った方が良いと思えてきました。
また、別の人も書かれていますが、GUI上の変更もコードになっていれば、Git上で追いやすいという利点があります。差分が分かりやすいからです。
短期的には少し余計に時間がかかるかもしれませんが、長期的にはデバッグや開発環境更新時のトラブルを減らすことが出来ると思います。
2017/06/24 13:13追記
実際にやってみると、座標の感覚になれていないところで時間がかかりますが、一度、作ってしまえば、再利用もやりやすいと思います。
同じ座標や同じ大きさのダイアログなどは結構ありますし、特定の種類のボタン(例えば、「OK」ボタンや「Cancel」ボタンなど)は常に同じような座標で使うので、それらは直ぐに作れる様になります。
もうしばらく、実際にやってみて、検証していきます。

関連記事

  1. AtomはUndo情報も覚えている

  2. HistoryEditor 1.5.1 Mac OS X版を公開しまし…

  3. 長く運用するサーバーは仮想マシンにしておこう

  4. 古いOS対応アプリを最新Xcodeで作る

  5. Mac版のNetbeansの設定ファイル

  6. 新年明けましておめでとうございます!

最近の著書

最近の記事