1.導入

ⅰ.ヒューマンインタフェースガイドライン

AppleがiOSアプリ開発者向けに公開しているガイドラインに準拠する。

ⅱ.プロジェクトのセットアップ

①UIについて

1)UIは、ストーリーボード(Storyboard)を利用すること。

　UIとロジックを切り離し、ソースコードはロジックに専念するため

2)ストーリーボードは、1画面1ファイル作成する。

　ストーリーボードは、複雑なXML形式のため、バージョン管理で競合が発生しやすい。
　そのため、競合の発生頻度を減らすために、1画面1ファイル作成する。
　なお、ストーリーボード名、storyboard identifierは、クラス名と同名とする。

例）Swiftの場合

├─ SampleViewController.swift
├─ SampleViewController.storyboard

final class SampleViewController: UIViewController {

    // storyboard identifierは、クラス名と同名
    static var identifier: String {
        return String(describing: self)
    }
}

②ファイル管理

1).gitignore を用意する。

　不要なファイル（ユーザ設定や一時ファイル）をリポジトリに保存されないようにする。

・swift-gitignore
・objc-gitignore

例) .gitignore

2)ブランチ

git-flowモデルに準拠する。

3) コメント

gitのコメントは、変更種別、変更内容および、Issue/Backlog番号が分かるように入力する。

変更種別	説明
バグ修正	Fix + [修正内容] + (Issue番号)
機能追加	Add + [追加内容] + (Issue番号)
機能変更	Update + [変更内容] + (Issue番号)
ファイル削除	Remove + [削除ファイル] + (Issue番号)
リネーム	[以前の名前] to [現在の名前] + (Issue番号)

③ライブラリ管理

ライブラリは、Cocoa Podsまたは、Carthageを利用する。
どちらを利用するか、または共存するかは個別のプロジェクト方針に従う。

1) Cocoa Pods

プロジェクトごとに CocoaPodsのバージョンを合わせる場合は、Bundlerを利用すること。

Cocoa Podsの導入方法は、こちらを参照

Bundlerの導入方法は、こちらを参照

ライブラリバージョンの指定

Podfileに追加したライブラリは、バージョンを指定すること。

platform :ios, '9.0'
use_frameworks!

target 'Sample' do
pod 'Alamofire', '4.4'
end

2) Carthage

Carthageの導入方法はこちらを参照

ⅲ.プロジェクトの構成

MVCにより下記のようなディレクトリ構成を維持する。

    ├─ Models         // モデルを格納するディレクトリ
    ├─ Views　　　　　　　　　　　　　　　　　　　　// ビューを格納するディレクトリ（UIViewから派生するサブクラス）
    ├─ Controllers    // ビューコントローラを格納するディレクトリ (Storyboardを含む）
    ├─ Helpers        // ヘルパーを格納するディレクトリ（複数のクラスから利用される共通のロジック）
    ├─ Extensions     // エクステンションを格納するディレクトリ(iOS-SDK提供の拡張クラス）
    ├─ Others         // 上記に含まれないクラスを格納するディレクトリ

XCodeと実際のディレクトリ構成に差がでないように、
「synx」コマンドで同一ディレクトリ構成を保つ。
synxの導入方法は、こちら

① ローカライゼーション

ユーザが画面を通して目にする文字列は、localizable.strings に定義する。

② 定数

定数のスコープは限りなく狭くする。
クラス内のみで利用する場合は、クラス内で定義すること。

アプリ全体で利用する定数は、Constants.swift ファイルで定義された構造体を使用する。

③ アセット

アイコンや起動画面等の画像は、Asset Catalog（.xcassets）で管理すること。
画像ファイルの追加・削除・修正を行ってもプロジェクトファイルは変更されないため、
gitでのコンフリクトを避けることができる。

画像のファイル名のネーミングについて

画像のファイル名は、下記のとおりとする。

・iPhone-<画面名>-<画像名>.png
・iPad-<画面名>-<画像名>.png

※なお、汎用的に使う画像は画面名をCommonとする。

例）
・[email protected]
・[email protected]
・[email protected]

2. ライブラリ

ⅰ.AFNetworking / Alamofire

ネットワークのライブラリは、AFNetworkingまたは、Alamofireを利用する。

・AFNetworking
・Alamofire

ⅱ.Mantle / ObjectMapper

JSONデータのマッピングは、Mantleまたは、ObjectMapperを利用する。

・Mantle
・ObjectMapper

ⅲ.Realm/FMDB

データベースは、Realmまたは、FMDBを利用する。

・Realm
・FMDB

ⅳ.SDWebImage/Kingfisher

ネットワークからの画像取得ライブラリは、SDWebImageまたはKingfisherを利用する。

・SDWebImage
・Kingfisher

3. アーキテクチャ

アーキテクチャの選定は、チーム規模やメンバーのスキルセットによって判断すること。

ⅰ.Model-View-Controller(MVC)

Appleのアーキテクチャ(MVC)

https://developer.apple.com/library/content/documentation/General/Conceptual/DevPedia-CocoaCore/MVC.html

ⅱ.Model-View-ViewModel(MVVM)

https://www.objc.io/issues/13-architecture/mvvm/

├─ Models
├─ ViewModels
├─ Views
├─ Controllers

ⅲ.The Clean Architecture

http://blog.tai2.net/the_clean_architecture.html

├─ Data
├─ Domain
├─ Presentation 
├─ Util

ⅳ.イベントパターン

パターン	説明
デリゲーション	1対1の関係で値を返したいときに利用する。
クロージャー/ ブロック	1対1の関係で値を返したいときに利用する。関連するコードを近づけて結合させたいときに利用する。
通知センター	1対多の関係でオブジェクトが複数のオブザーバーに対してイベントを発行するときに利用する。
KVO	1対多の関係で監視されたキーに対して明示的にイベントを発生するときに利用する。

4. コーディングスタイル

ⅰ.ネーミング

Apple の [Objective-C のためのコーディングガイドライン][cocoa-coding-guidelines] と
[Swift のための API 設計ガイドライン][swift-api-design-guidelines] を厳守する。

・cocoa-coding-guidelines
・swift-api-design-guidelines

ⅱ.コーディング規約

弊社の[Swiftコーディング規約]と[Objective-C コーディング規約]に準拠する。

・Swiftコーディング規約
 ・Objective-C コーディング規約

①静的解析ツール

静的解析ツールは、SwiftLintを利用する。
SwiftLintは、チーム内で可読性を維持する目的で導入します。

SwiftLintの導入方法は、こちら
SwiftLintのルール(.swiftlint.yml)は、こちら

5. SwiftとObjective-Cの相互利用

ⅰ. Swiftのプロジェクトの中でObjective-Cのクラスを利用する

ブリッジヘッダファイルを作成し、Objective-Cのクラスをimportする。

例）　<プロジェクト名>-Bridging-Header.h

#import "SampleObjCObject.h"

① XCodeのブリッジヘッダファイル作成ダイアログから作成する場合

1.Objective-C のファイルを新規作成する
2.ダイアログが表示されたあとで、Yesを押下する

② XCodeのブリッジヘッダファイル作成ダイアログから作成しない場合

設定方法は、こちら

ⅱ. Objective-Cのプロジェクトの中でSwiftのクラスを利用する

<プロジェクト名>-Swift.hをimportする。

#import "ProjectName-Swift.h"

注意する点

・利用できるクラスは、NSObjectのサブクラスであること。
・構造体は、アクセスできないため注意が必要。

例)

final class SampleSwiftClass: NSObject  {
    var name = ""
}

その他のポイントは、こちら

6. セキュリティ

ⅰ.データ・ストレージ

ユーザ名や認証トークンなど、ユーザの個人情報を保存する場合は、
NSUserDefaultsやCoreData等に保存してはいけない。
このような慎重に扱うべくデータは、キーチェーンを利用する。(SSKeychain)

ⅱ.ネットワーク

通信の内容が暗号化されるHTTPS接続の利用する。

ⅲ.ログ

アプリを公開する前に、適切なログレベルを設定する。
プロダクトビルドでは、ログを表示しないうようにする。

ⅳ.UI

パスワード入力時にUITextFieldを利用する場合は、
パスワードがクリアテキストで表示されるのを避けるため、
secureTextEntryをtrueにしておく。

ⅴ.センシティブな情報

センシティブな情報（API Key等）は、
cocoapods-keysを利用して、プロジェクト環境から切り出して管理すること。

cocoapods-keysの導入方法は、こちらを参照
なお、.env ファイルを.gitignoreに追加しておくこと。

7. ビルド

ⅰ.スキーム

スキームに推奨される命名規則は、MyApp[テスト環境]とする。

テスト環境	スキーム名
開発環境	MyApp[Development]
ステージング環境	MyApp[Staging]
本番環境	MyApp[AppStore]

Info.plist名

Info.plist名は、下記のとおりとする。

テスト環境	ファイル名
開発環境	MyApp-development.plist
ステージング環境	MyApp-staging.plist
本番環境	MyApp-appstore-Info.plist

マクロ名

マクロ名は、下記のとおりとする。

テスト環境	マクロ名
開発環境	DEVELOPMENT
ステージング環境	STAGING
本番環境	-

例） URLの向き先を変える場合の例

    var baseUrl: String {
        #if DEVELOPMENT
            return "https://dev-foo.bar.jp"
        #elseif STAGING
            return "https://stg-foo.bar.jp"
        #else
            return "https://prod-foo.bar.jp"
        #endif
    }

8. 解析

ⅰ. クラッシュログ

クラッシュログにアクセスするために、Fabric(Crashlytics)を利用すること。

・Fabric

ⅱ. アナリティクス

アプリのアクセス解析のために、Google Analyticsまたは、Firebaseを利用すること。

・Google Analytics
・Firebase

9. ツール

ⅰ. Charles

https通信をキャプチャするツールです。
導入方法はこちらを参照

https://www.charlesproxy.com/download/latest-release/

ⅱ. Deploygate

デプロイするツールです。

https://deploygate.com/dashboard?locale=ja

ⅲ. DB Browser For SQLite

SQLite管理ツールです。

http://sqlitebrowser.org/

ⅳ. Doxygen

ドキュメント自動生成ツールです。
Objective-Cのみに対応しています。
Swiftには対応していません。
導入方法は、こちらを参照

http://www.doxygen.jp/

ⅴ.simpholders

アプリ管理ツールです。
アプリ内に保存したDBのパスを取得するときに便利です。

https://simpholders.com/