iOSアプリを新規作成するときに最低限どのプロジェクトでも守っていること(方針)をリストアップしました。
たまに、どんなことを他の案件でやったのか忘れるのでメモです。
リストアップしていることを守っておけばある程度の仕様変更などにも耐えやすいアプリが作成で来たので、気が向いたら試してみてください。
プロジェクトフォルダ内を適度にグループ分けする
グループわけされていないプロジェクトは、ぱっと見で何が何だか判断できないのでグループ機能を使用して見通しをよくする。
Web系のフレームワークのディレクトリ分けを参考にするといい感じになる。
// 個人的にはこんな感じで分けるのが好きです
Assets.xcassets
AppDelegate.swift
Common
- Model
- View
- Controller
- Utility
- Request
- Extension
- ...
Login
- Model
- View
- Controller
- Manager
- Request
ArticleList
- Model
- View
- Controller
- Request
また、無理して実ディレクトリ構成をグループ分けの構造に合わせなくてもいいと思う。
どうしても合わせたいときは、venmo/synxなどを導入して自動でやらせる。
適度にグループ分けされていない（クラスが100個ずらっと並んでるとか）プロジェクトを見ると発狂します。
基盤を作ってからModelを組む
通信周りなら、Alamofire+ObjectMapper
DB周りなら、Realm or CoreData(+MagicalRecord)
などをうまい具合にラップして、アプリの基盤を作る。
車輪の再発明さえしなければ、有名どころのものを使用すれば大体なんとかなるイメージ。
Modelはこれらを利用して組み込んでいく。
必要がないプロジェクトにはReactiveを導入しない
データが動的に変わらないアプリなどでは、Reactiveに頼らなくても簡単に実装できるので、無理にReactiveを導入しない。
使い方の問題かもしれないが、可読性が落ちるのと、Reactiveを使わない方がシンプルなコードになることが多いので、使用する場合もアプリ全体で無理に使わず、必要な箇所のみに絞った方がいい気がする。
MVVMとかもめんどくさいのでカスタムViewに任せちゃえばいいと思っている。
簡単に環境を切り替えられるように仕込む
Configurationsとスキームを設定してAPI URLなどを簡単に切り替えられるようにしておく。
テスト環境と本番環境のURLを手動で切り替えるのは極めて危険なので。
定数管理クラスを用意する
プロジェクト内に定数を管理するクラスをあらかじめ作っておく。
作っておけば、いろんなところに散らばることを防げて便利！
カラーコード管理クラスを用意する
上記と同じ
UserDefaults、Notificationもとりあえずまとめる
UserDefaultsを編集・取得するクラス、Notificationを飛ばすクラスを作成しておくと、仕様変更にちょっと強いアプリが作れる。
UserDefaultsの管理には、radex/SwiftyUserDefaultsとかを導入するとまとまる。
StoryBoardを適度に分割する
タブごと、機能ごとにStoryBoard分割しながらViewを組む。
分けすぎたら、StoryBoardの視認性がなくなるのでほどほどに。
AutoLayoutで
AutoLayoutは必須。
コードで描くときは、SnapKitなどを導入するとサクサク進む。
Controllerは使い捨てにするつもりで実装
Controllerは使い回すものではないので、とにかく小さくまとめることに集中する。
500行超えてきたら、相当まずい。
コード規約 各種お作法
コード規約
エラー処理
ある程度妥協する
妥協するタイミングは時と場合によって