Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationEventAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
6
Help us understand the problem. What are the problem?

More than 5 years have passed since last update.

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

はじめに

発表用メモです。

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

決断の積み重ね。
それは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画面ほど。
継承している画面もあるが、手を入れる時に気が重くなる。

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
6
Help us understand the problem. What are the problem?