私の現場での試行錯誤後のiOS開発方針

  • 7
    いいね
  • 4
    コメント
この記事は最終更新日から1年以上が経過しています。

はじめに

発表用メモです。

発表後、しばらくして消すかもしれません!
※ 追記:
誰かの参考になるかもしれませんので残しておきます。
また「これがベストプラクティス!」と考えている訳ではないですよー
あくまで現場での方針のいちサンプルとして見てください。

決断の積み重ね。
それはBad Know-how?それとも最適化した結果?

前提:

 iOSアプリプログラマ4人。
 iPadアプリのプロダクト3個。
 MRC(メモリマニュアル管理)の頃から継続開発。

本題:

チームでの方針:
1. 画面生成、コントロール生成、画面遷移はコードで行う
2. Storyboard使用しない
3. SizeClass使用しない
4. AutoLayout使用
5. オープンソース使用は控えめで、直接プロジェクトに追加
6. 基本的にviewDidLoadで画面レイアウト生成
7. 表示更新用メソッドを用意しそれを使用
8. 重い画面はviewDidAppearで(初回時のみ)レイアウト生成

※ 追記
発表後アドバイス受けました!
あらためて整理し考えなおしたら、8はやる必要なくてviewDidLoadで遅延実行の方が良いですね。
改善していきます!ありがとうございます。

※ 追記
オープンソース使用時はCocoaPods等パッケージマネージャを使うべきです。

某大手iOS開発会社のデザイナ兼エンジニアにヒアリング

・Storyboard、Xib使用
・SizeClass 使用していない
・AutoLayout ヘビーに使用している
・StoryBoardは1〜3画面につき1ファイル 厳密に決めていない
・コードでの画面系制御は本当に必要最低限にする

蛇足:

・正直に言うとdidReceiveMemoryWarningをきっちり実装した試しがない
・個人で作る場合、Storyboard使用するが"画面の器の置き場"
・個人で作る場合、CocoaPods経由でオープンソース使い倒し
・コードで画面コントロール生成することに対して全面賛成ではない
・SVProgressでロード中操作制御
・NSNotificationは使わない
・UIView、UIViewControllerの継承は控えめに

現在アプリ1つで40画面ほど。
継承している画面もあるが、手を入れる時に気が重くなる。