iOS開発(swift)のおすすめ構成〜パッケージマネージャ編〜

はじめに

iOS開発のおすすめライブラリとか書いておすすめ構成をちゃちゃっと書こうかなと思ったんですがせっかくなんでライブラリ以外も含めたプロジェクト構成を書こうと思います。長くなりそうなんで下記3つに分けようと思います。

パッケージマネージャ編（CocoaPodsの使い方とか）
おすすめライブラリ編（R.swift など定番のやつとか）
プロジェクト構成編（モジュール分割とか）

今回は CocoaPods, Carthage, Swift Package Manager といったパッケージマネージャについてです。

CocoaPods

CocoaPods とは、サードパーティ製のパッケージマネージャです。Podfile の記述とターミナルでのコマンドで管理ができます。

CocoaPods.org

The Dependency Manager for iOS & Mac projects

仕組みはあんまわかってないですが。。。この記事（CocoaPodsによる、外部ライブラリの利用と作成）によるとらしいです。

ざっくりと外観してしまうと・・・CocoaPodsは、Podfileに記述されたライブラリを、メタ情報をもとにダウンロードし、それらをまとめたPodsプロジェクトを生成します。そして、ワークスペースの仕組みを利用して、既存のプロジェクトから、これを参照できるようにしています。

https://github.com/CocoaPods/Specs/tree/master/Specsでライブラリの情報が管理されてるらしいです。（たぶんここに podspec の情報がある）

自作ライブラリのCocoaPodsは下記記事をどうぞ。

自作ライブラリのCocoaPods対応

インストール方法

ターミナルで下記コマンドを実行するとインストールできる

$ sudo gem install cocoapods

1	$ sudo gem install cocoapods

インストール後は下記もやった方がいいらしい（なくてもいけるのでよくわからない。。。）

$ pod setup

1	$ pod setup

下記でバージョン指定してインストールもできる

$ gem install -v 1.9.0 cocoapods

1	$ gem install -v 1.9.0 cocoapods

バージョン確認

$ pod --version

1	$ pod --version

アンインストールする場合は下記（バージョン指定もできるみたい）

$ gem uninstall cocoapods

1	$ gem uninstall cocoapods

使い方

基本的にはターミナルで操作します。コマンド詳細は Command-line Reference をどうぞ。

使うのは下記コマンドくらいだと思います。

pod init
pod install
pod update

Xcode のプロジェクトフォルダに移動し下記コマンドを実行する。

$ pod init

1	$ pod init

Podfile が作成されるのでライブラリを入れたいターゲットに指定のライブラリを記述します。

ライブラリのバージョン指定方法は下記。基本的にはバージョンを固定した方がいいと思います。

pod 'AMColorPicker' // 最新
pod 'AMColorPicker', '2.0' // 2.0
pod 'AMColorPicker', '>= 1.0' // 1.0以上の最新 
pod 'AMColorPicker' '~> 1.0' // 1.0以上2.0未満の最新

pod 'AMColorPicker' // 最新

pod 'AMColorPicker', '2.0' // 2.0

pod 'AMColorPicker', '>= 1.0' // 1.0以上の最新

pod 'AMColorPicker' '~> 1.0' // 1.0以上2.0未満の最新

下記コマンドを実行してライブラリ導入は完了。

$ pod install

1	$ pod install

上記コマンドを実行すると Podfile.lock と Workspace ファイルが作成されるので Xcode で作業をする場合は Workspace ファイルを開いて作業する。

複数のターゲットで共通のライブラリ利用する場合は Podfile に下記のように書くこともできます。

# Uncomment the next line to define a global platform for your project
platform :ios, '13.0'

def common_install_pods
  pod 'AMClockView', '2.1.0'
  pod 'AMNowClockView', '2.2.0'
end

target 'Target1' do
  # Comment the next line if you don't want to use dynamic frameworks
  use_frameworks!

  # Pods for Target1
  pod 'AMColorPicker', '3.0.1'
  common_install_pods
end

target 'Target2' do
  # Comment the next line if you don't want to use dynamic frameworks
  use_frameworks!

  # Pods for Target2
  pod 'AMJpnMap', '2.1.1'
  common_install_pods
end

# Uncomment the next line to define a global platform for your project

platform :ios, '13.0'

def common_install_pods

pod 'AMClockView', '2.1.0'

pod 'AMNowClockView', '2.2.0'

end

target 'Target1' do

# Comment the next line if you don't want to use dynamic frameworks

use_frameworks!

# Pods for Target1

pod 'AMColorPicker', '3.0.1'

common_install_pods

end

target 'Target2' do

# Comment the next line if you don't want to use dynamic frameworks

use_frameworks!

# Pods for Target2

pod 'AMJpnMap', '2.1.1'

common_install_pods

end

これで AMClockView と AMNowClockView を複数ターゲットで利用できます。

更新

ライブラリのバージョンを更新する場合はよく pod install と pod update どちらを使うのかという話がありますが私は基本的には pod install を使えばいいと思います。

Podfile にはライブラリのバージョンを記述し更新する場合は Podfile を更新して pod install を実行するとライブラリの更新できます。

pod install と pod update の違い

ライブラリをインストールするとライブラリのバージョンなどが Podfile.lock に記録されます。

pod install は Podfile.lock の情報をみてライブラリのインストールを行います。これにより複数人の開発環境で同じバージョンのライブラリをインストールすることができます。
Podfile の記述を更新して pod install を実行すれば Podfile をみにいってくれるので Podfile を更新すれば pod install でライブラリの更新は可能です。（ちゃんと Podfile.lock も更新してくれます。）

pod update は Podfile でバージョンを指定していない場合にライブラリの新しいバージョンがリリースされていれば、新しいバージョンのライブラリをインストールしてくれます。pod install の場合はライブラリの新しいバージョンがリリースされていてもアップデートはしません。

Podfile でライブラリのバージョンを指定していれば pod update を使うことはないのかなと思います。pod install との違いとして pod update <ライブラリ> のように指定のライブラリのみ更新が行えますがこちらも Podfile でライブラリのバージョンを指定していれば使うことはないのかなと思います。

pod install と pod update の詳しい違いは下記をどうぞ。

pod install vs. pod update

削除

使わないライブラリを削除したい場合

Podfile から指定のライブラリの記述を削除し pod install を行うと削除できます。

プロジェクトから CocoaPods 関連のものをすべて削除したい場合

Xcode のプロジェクトフォルダで下記コマンドを実行する。

$ pod deintegrate

1	$ pod deintegrate

上記コマンド実行後、Podfile, Podfile.lock, Workspace ファイルを削除すれば完了です。

Command-line Reference - pod deintegrate

開発者の環境を揃える

CocoaPods を複数人開発で利用する場合、それぞれの開発者の CocoaPods のバージョンを揃えた方が事故がなくていいです。バージョンを揃えるために rbenv と bundler を利用します。

Homebrew で rbenv をインストールします。（Homebrew が入っていない場合は Homebrew に書いてあるインストールコマンドを実行します）

$ brew install rbenv ruby-build

1	$ brew install rbenv ruby-build

後は下記手順で実行

// 1. インストール可能な ruby バージョンを調べる
$ rbenv install -l

// 2. 指定のバージョンの ruby をインストール
$ rbenv install <バージョン>

// 3. 使用する ruby バージョンを指定（.ruby-version ができるはず）
$ rbenv local <バージョン>

// 4. .zprofileに「eval "$(rbenv init -)"」追記

// 5.インストールした ruby を使用可能な状態にする
$ rbenv rehash

// 6. ターミナル再起動（.zprofile のやつ反映するため）

// 7. ruby のパス（/.rbenv/shims/rubyになっていれば成功）
$ which ruby

// 8. bundler をインストール
$ gem install bundler

// 9. bundler 設定（Gemfile ができるはず）
$ bundle init

// 10. Gemfileに「gem "cocoapods", "<バージョン>"」を追加

// 11. cocoapodsをインストール（Gemfile.lock ができるはず）
$ bundle install --path vendor/bundle

// 1. インストール可能な ruby バージョンを調べる

$ rbenv install -l

// 2. 指定のバージョンの ruby をインストール

$ rbenv install <バージョン>

// 3. 使用する ruby バージョンを指定（.ruby-version ができるはず）

$ rbenv local <バージョン>

// 4. .zprofileに「eval "$(rbenv init -)"」追記

// 5.インストールした ruby を使用可能な状態にする

$ rbenv rehash

// 6. ターミナル再起動（.zprofile のやつ反映するため）

// 7. ruby のパス（/.rbenv/shims/rubyになっていれば成功）

$ which ruby

// 8. bundler をインストール

$ gem install bundler

// 9. bundler 設定（Gemfile ができるはず）

$ bundle init

// 10. Gemfileに「gem "cocoapods", "<バージョン>"」を追加

// 11. cocoapodsをインストール（Gemfile.lock ができるはず）

$ bundle install --path vendor/bundle

これで実行環境は完成！ pod コマンドを実行する場合は bundle exec pod install のようにする。

gitignoreの設定

上記の手順で CocoaPods を導入すると下記のフォルダやファイルが生成されるはず。

.ruby-version
Gemfile
Gemfile.lock
/vendor/bundle
/.bundle
Podfile
Podfile.lock
Workspaceファイル
/Pods

この中で gitignore で除外するのは /vendor/bundle と /.bundle のみで他はすべて push します。
Podsフォルダに関しては push するかどうかは意見が分かれるところですが私は pull 後にすぐ起動できる利点を重視して push しています。（push しなくても pod install で同一のライブラリの取得は可能です）

gitignore には下記を追記する

vendor/bundle/
.bundle/

1 2	vendor/bundle/ .bundle/

Pods を push するかどうかは下記記事を参考にどうぞ。

CocoaPods・Carthageでインストールした成果物はバージョン管理に含めるべきか？

Carghage

Carthage とは、サードパーティ製のパッケージマネージャです。読み方はカルタゴかカーセッジ。（前の現場はカルタゴで今の現場はカーセッジって言ってます）Swift で書かれてるらしいです。CocoaPods よりも色々手順がめんどくさい。

Carthage/Carthage

自作ライブラリの Carthage 対応は下記記事をどうぞ

自作ライブラリのCarthage（カルタゴ）対応

インストール

Homebrew で Carghage をインストールします。（Homebrew が入っていない場合は Homebrew に書いてあるインストールコマンドを実行します）

$ brew install carthage

1	$ brew install carthage

バージョン確認

$ carthage version

1	$ carthage version

アンインストールする場合は下記

$ brew uninstall carthage

1	$ brew uninstall carthage

使い方

基本的にはターミナルでの作業になります。使うコマンドは下記くらいかと思います。

carthage update
carthage bootstrap

導入

Cartfile 作成

Xcode のプロジェクトフォルダで Cartfile をつくる。（エディタでも touch Cartfile コマンドでも OK）
Cartfile に利用するライブラリを記述します。

ライブラリのバージョンしてい方法は下記。基本的にはバージョンを固定した方がいいと思います。

github "adventam10/AMNowClockView" // 最新
github "adventam10/AMNowClockView" == 2.0 // 2.0
github "adventam10/AMNowClockView" >= 1.0 // 1.0以上の最新 
github "adventam10/AMNowClockView" ~> 1.0 // 1.0以上2.0未満の最新

github "adventam10/AMNowClockView" // 最新

github "adventam10/AMNowClockView" == 2.0 // 2.0

github "adventam10/AMNowClockView" >= 1.0 // 1.0以上の最新

github "adventam10/AMNowClockView" ~> 1.0 // 1.0以上2.0未満の最新

ライブラリをビルド

Cartfile を作成したら下記コマンドを実行する。（Cartfile.resolved ができる）

$ carthage update --platform iOS --no-use-binaries

1	$ carthage update --platform iOS --no-use-binaries

オプションを指定せずに carthage update をすると iOS 用以外の macOS, tvOS, watchOS 用もビルドされるので --platform iOS を指定する。--no-use-binaries を指定しない場合、ライブラリのリポジトリにバイナリがあればそれを利用するがビルド時の Swift バージョンが古い可能性があるのでとりあえずこのオプションも付けとけばいいと思います。（Swift 5 では ABI 安定化対応しているので問題ないかもですが。。。）

Cartfile.resolved にはビルドしたライブラリ情報が記録されます。（CocoaPods の Podfile.lock のようなものです）

これでライブラリのビルドは完了！

プロジェクトにライブラリを追加

General -> Frameworks, Libraries, and Embedded Content -> ＋ -> Add Other... から下記のようにライブラリを追加する。（Finder からドラッグ＆ドロップでも可）

Embed は Do Not Embed を選びます。（これやっとかないと ipa 作成でエラーになります。）

プロジェクトにスクリプトを追加

Build Phases -> ＋ -> New Run Script PhaseでRun Scriptを追加する。

スクリプトに /usr/local/bin/carthage copy-frameworks と記述する。
Input Files に $(SRCROOT)/Carthage/Build/iOS/AMCalendar.framework を追加する。
Output Files に $(BUILT_PRODUCTS_DIR)/$(FRAMEWORKS_FOLDER_PATH)/AMCalendar.frameworkを追加する。

こんな感じ

Output Files の記述はなくてもいけるけど公式では書いてあった。ビルドが速くなるらしい。詳しくは下記をどうぞ。

CarthageのビルドフェイズでOutput Files指定による速度調査

更新

ライブラリのバージョンを更新する場合は Cartfile のバージョンを更新して carthage update --platform iOS --no-use-binaries で更新ができます。
一部のライブラリのみ指定したい場合は下記のように指定できます。

$ carthage update <ライブラリ名> --platform iOS --no-use-binaries

1	$ carthage update <ライブラリ名> --platform iOS --no-use-binaries

複数指定も可能

$ carthage update <ライブラリ名> <ライブラリ名> --platform iOS --no-use-binaries

1	$ carthage update <ライブラリ名> <ライブラリ名> --platform iOS --no-use-binaries

carthage update と carthage bootstrap の違い

2つの違いは CocoaPods の pod install と pod update に似ています。違うのは carthage bootstrap は常に Cartfile.resolved を見に行くことです。Cartfile を更新して carthage bootstrap をしても Cartfile.resolved の情報をみてビルドを行います。

carthage bootstrap は複数人開発などで共通のライブラリをビルドするときに使います。（pull 後とか）

bootstrap の場合も下記のようにオプションを指定したほうがいいと思います。

$ carthage bootstrap --platform iOS --no-use-binaries

1	$ carthage bootstrap --platform iOS --no-use-binaries

削除

使わないライブラリを削除したい場合

General -> Frameworks, Libraries, and Embedded Content で指定のライブラリを削除
Build Phases -> Run Script -> Input Files で指定のライブラリを削除
Build Phases -> Run Script -> Output Files で指定のライブラリを削除
Cartfile から指定のライブラリを削除
Carthage ディレクトリ削除（該当ライブラリだけで問題ないが色々あるのでこれ毎削除しちゃってもいいかも）
carthage update --platform iOS --no-use-binaries コマンド実行
Frameworks から指定のライブラリを削除

7 は下記のやつ

プロジェクトから Carthage 関連のものをすべて削除したい場合

General -> Frameworks, Libraries, and Embedded Content で指定のライブラリを削除
Build Phases -> Run Script で Run Script を削除
Build Settings -> Framework Search Paths から Carthage の記述を削除（Cart で検索すると出るはず）
Cartfile を削除
Cartfile.private を削除
Cartfile.resolved を削除
Carthage ディレクトリ削除
Frameworks から指定のライブラリを削除

Cartfile.private

リリース用にはいらないライブラリ（テスト用など）は Cartfile ではなく Cartfile.private に記述します。（Cartfile 同様作成はエディタでも touch Cartfile.private コマンドでも OK）

記述方法は Cartfile と同じです。

xcfilelist

Input Files と Output Files にライブラリを一つずつ追加したけど xcfilelist を使う方法もあるみたいです。コメントも書けてこっちの方が見やすくていい！

参考：XcodeのBuildPhase RunScript でxcfilelistを使う

プロジェクトに xcfilelist を追加する。

Input 用（CarthageInput.xcfilelist）と Output 用（CarthageOutput.xcfilelist）を作成する。

CarthageInput.xcfilelist

# コメントも書ける
$(SRCROOT)/Carthage/Build/iOS/AMClockView.framework
$(SRCROOT)/Carthage/Build/iOS/AMCalendar.framework

# コメントも書ける

$(SRCROOT)/Carthage/Build/iOS/AMClockView.framework

$(SRCROOT)/Carthage/Build/iOS/AMCalendar.framework

CarthageOutput.xcfilelist

# コメントも書ける
$(BUILT_PRODUCTS_DIR)/$(FRAMEWORKS_FOLDER_PATH)/AMCalendar.framework
$(BUILT_PRODUCTS_DIR)/$(FRAMEWORKS_FOLDER_PATH)/AMClockView.framework

# コメントも書ける

$(BUILT_PRODUCTS_DIR)/$(FRAMEWORKS_FOLDER_PATH)/AMCalendar.framework

$(BUILT_PRODUCTS_DIR)/$(FRAMEWORKS_FOLDER_PATH)/AMClockView.framework

Run Script はこんな感じ

gitignoreの設定

上記の手順で Carthage を導入すると下記のフォルダやファイルが生成されるはず。

Cartfile
Cartfile.private
Cartfile.resolved
/Carthage

この中で gitignore で除外するのは /Carthage ディレクトリ内の /Build 以外です。（Cartfile, Cartfile.private, Cartfile.resolved は push します）
こんな感じ。

Carthage/Checkouts
!Carthage/Build

1 2	Carthage/Checkouts !Carthage/Build

サイズが大きいので Carthage ディレクトリを push するかは意見が分かれるところですが pull 後すぐに起動できる利点を優先して私は push しています。（Carthage ディレクトリを push しなくても carthage bootstrap で同一のライブラリの取得は可能です。）

下記のような管理方法もあるそうです。

iOS開発における最強のパッケージ管理方法

Swift Package Manager

Swift Package Manager （以下 SPM）は、ついに登場した純製のパッケージマネージャです。（前からあったけどたぶん iOS で使えるようになったのは Xcode 11 からのはず）Xcode だけで完結するのですごく簡単にライブラリを導入できます。ただ、まだまだ SPM に対応していないライブラリも多いです。。。

SPM リポジトリ

自作ライブラリの SPM 対応は下記記事をどうぞ

自作ライブラリのSwift Package Manager(SwiftPM)対応