iOSアプリの引き継ぎしている

理由あって、仕事でやっていたiOSアプリの開発を抜けることになった。

新しい担当者は、いつかあちこち変更したい気持ちになと思うので、もちろんどんどんやってもらって構わないけど、変更していいのか確信に至れなかったときのため、現状なぜこうなっているのかの理由を書き残しておくことにした。きっと、ちかい将来に役に立つときもあるとおもう。

内容は異論もあると思うけど、せっかくなので、汎用的な部分を、ここにもすこし公開していくことにした。

--

Storyboardは善良

このアプリでは、Storyboard で設定できることは、可能なかぎりStoryboardでやっています。

普段、Webサービス開発をしていると、HTML/CSS とか、人間も機械も読み書き可能なテキストを編集していく、この Linux的なノリによって UIを組み立てることに慣れているかもしれません。これは、どんな環境でも好きなエディタで開け、競合してもマージでき、オープンソースと相性が良いやりかたであることは間違いありません。

しかしテキスト編集による開発だけがすべてではありません。iOSのコードはビルドに時間のかかる言語でできていますし、LL言語のランタイムを組み込んで動作を制御するレイヤーみたいなものもありません。UIを表現したXMLファイル(xib)も実行時にバイナリにコンパイルされ、基本的には文字をなにか書くと再ビルドに時間がかかると考えた方が良いです。

それに、ネイティブアプリケーションは、標準化されたUIコンポーネントを並べるだけじゃなくて、なんでもできるし、ドキュメント化できない触り心地みたいなものも大事です。あるとき「動いているものを目視しないことには良いのか悪いのか判断しかねまっす」といった部分がたくさんあることに気がつきます。とくにそのような箇所では、できるだけコードをビルドせずにリアルタイムに直感的に変更が確認できる部分が多いワークフローが大事だと考えていました。

つまり Storyboard は iOSの良心なんです!

極端に言うと、UIコンポーネントの位置を調整したいとき、コードを編集してビルド開始して10秒待つ、を100回繰り返すより、リアルタイムに変更が即座に反映されるStoryboard 上でマウスを100回ポチポチするほうが 1000倍速いです。いかにビルドをせずに変更を確認できるかということを本来は考えていくべきだったと思います。

とくに、Autolayoutには注意です。Autolayoutをコードによって設定するとき、それはそれはちょっとした独自言語のようなデザインになっていて、実行時でないと結果が確認できないばかりか、コンパイル時に誤りを検出することもできないのです。Autolayoutをコードで設定するメリットはかなり弱いと思います。そんなわけでできるだけ Storyboard に寄せよう。

コードから動的にレイアウトを変更する必要に迫られたときは以下のようなことをしていました。 * Storyboard上で定義した制約を、コードからIBOutletで参照しておき、実行時に制約の値だけを動的に変える。 * 共通部品については、xibで定義して、コードからはめこむようにしたり * 動的に画面遷移先が変わるような場合も、コードからセグエを実行したり、カスタムセグエを定義するようにしていました。

vimさえあればStoryboardなんていらないさ。おれは暗黒VimのDark powerで、vim からiOSシミュレーターを操作する術さえ心得ているんだ」 そこのきみ、さあ今すぐ武器をすてて両手を頭の上に置いて! ていこうしても無駄だよ。きみだって、いつかこんな日がくるってわかっていたはずさ。どんな友情も、終わりがあるからこそ美しいとはおもわないかい?

ライブラリは最期の手段

このアプリ では、外部ライブラリを使うことにとっても慎重な考え方をしていました。

UIコンポーント

とくに、UIコンポーネントそのものが切り出され提供されているライブラリはかなり意識的に使わないようにしていました。 この分野で人気のあるものは、たとえば、画面のド真ん中に読み込み中をあらわす「ぐるぐる」がいっちょまえに表示されるものとかですね。 しかし、このようなものを作るには特別な知識はとくに必要なく、iOS開発者を自認する方々なら30分くらいで書ける程度のものではないでしょうか。 (もちろんインターフェイスの良し悪しや完成度など品質の違いはあれど)

こうした使いまわしUIコンポーネントは、UIKit のカスタマイズ方法がわからない片手間の開発者や、デザイナがいないプロジェクトなどにとっては有益だと思いますし、実際助かる人が多いはずだと思いますが、目的を品質の高いUIに絞って考えたとき、UIコンポーネントはプロダクトのデザインとしてふさわしいものを一から考えることがより良い方法であると考えています。

Web開発に慣れていると、仕様がある部分だったり、皆の欲しいものが一致しているレイヤについては、積極的に品質の高いオープンソースライブラリを当てはめていくといった考え方でうまくいった経験を多くしていると思いますが、フロントエンドのレイヤーに下りてくると、そのバランスがもっと微妙になってきます。(もっともっと下りていくとこの道はデザイナにつながっていることを想像してください)

UIコンポーネントライブラリの大半は、設定によって柔軟に挙動を変えるためのコードでできています。そういうものをとっぱらってコアな部分だけをとりだすと、ほらみてください。せいぜい 10-50行くらいでしょ。ほら。ほら。 使いたい動きやUIのライブラリをみつけた際は、しくみをざっと読んでエッセンスだけとりこんで4秒くらいで実装しましょう。君にはそれができるはずです。そのほうが柔軟にプロダクトにフィットするものができ、挙動のカスタマイズ、見た目のカスタマイズも簡単で、負債にもなりません。 世の中のすてきなアプリをみて、フロントエンドはそれくらいアプリごとに作りたいものに開きがあると知りましょう。

HTTP

この話は、 UIコンポーネントに限った話ではありません。プロダクトごとにスタイルが違う要素に関しては注意です。

人気のあるものところでは、HTTPクライアントの使いやすいインターフェイスを提供する Alamofire もかなり意識的に使っていません。 こういう類のものは、必ずしも使えないというわけではないですが、標準ライブラリと比べてパラダイムが何も変わっていない。ただのコールバックベースです。より設計に気をつかっているプロジェクトでは、Rx を採用していたり、野良Promise的なものを採用していたり、非同期処理そのものをオブジェクトとして表現する統一的な方法を導入するはずで、 HTTP も同じスタイルに統合していくにあたって、 Alamofire を導入するメリットがありません。