現在のiOSアプリ開発におけるパッケージマネージャのデファクトスタンダード(事実上の標準)としてCocoaPodsとCarthageがあります。ManagerがXcodeに統合されて利用できますが、ライブラリ側の対応が必要ということや、ベンダーライブラリなどを考えるとCocoaPodsは少なくとも当面は使われ続けるでしょう。Carthageと違って、CocoaPodsは.xcodeprojに依存せず独自のビルドシステムを持つことや、(デフォルトでは)Workspaceにライブラリのプロジェクトを自動的に統合するので、リンクに関する設定をやらなくて済むという特徴があります。これは長所でもあり短所でもあります。リンクの設定を自動で追加するために、プロジェクトのビルド設定がCocoaPodsが自動で追加する記述によって非常に複雑になり、ライブラリの追加削除による.xcodeprojファイルのコンフリクトの解決は非常に大変です。ワークスペースにCocoaPodsが管理するプロジェクトとして導入されるので、クリーンビルドの際はライブラリがすべて再ビルドされるため、非常に時間がかかってしまう問題があります。(そしてiOSアプリの開発では謎のエラーによってクリーンビルドをしなければならないことがそこそこの頻度で発生します。)Carthageではビルド済みライブラリとして導入されるので、クリーンビルドの問題はおこりませんが、Firebaseなど公式にはCarthageの導入をサポートしていないライブラリもあります(実験的にCarhtageインストールも用意されています)。この問題は、CocoaPodsをWorkspaceに自動統合しない設定で利用することにより解決できます。デメリットは、Workspaceが自動統合されないため、導入したライブラリをリンクする設定は自分で書く必要があることです。CocoaPodsが自動的に行っていたライブラリのリンク設定を1つずつ記述していくのはそれなりに大変ですが、CocoaPodsの自動設定は前述のように.xcodeprojファイルを複雑にしてコンフリクトの解決を不可能にするという問題もあります。この問題はリンク設定をマニュアルで行う場合は.xcodeprojファイルではなく.xcconfigに記述できるので、.xcodeprojファイルをシンプルに保つことができます。FrameworkをCocoaPodsで導入する場合、複数のターゲットが存在する場合は、重複してリンクしてしまう問題を簡単には避けられません。マニュアルですべてのライブラリをリンクしていくなら、確実に必要なターゲットを選んでリンクできるのでこの問題も解決できます。(リンクに関する知識がそれなりに必要ですが、複数のターゲットにライブラリを導入するくらい複雑になってくると、どのみちリンクの知識は必要なので、CocoaPodsのバッドノウハウと格闘するよりは素直にリンクについて勉強する方が良いと思います。)実践PodfileCocoaPodsのライブラリをWorkspaceに自動統合しないようにするには、Podfileに次の記述を追加します。false例えば、下記のようになります。した場合、CocoaPodsは特定のプロジェクトと関係しなくなるので、自由にターゲットを構成してグループ化できます。'LicensePlist'上記の例では、SharedターゲットはFramework形式でビルドされます。4.2モードでビルドされます。Shared-StaticターゲットはStaticライブラリとしてビルドされます。TestsはFramework形式でビルドされます。4.2モードでビルドされます。このように、各ライブラリごとに柔軟に設定を変更してビルドできるのもCocoaPodsとCocoaPodsをWorkspaceに統合しない利点です。falseを設定した場合、ライブラリのプロジェクトはPodsディレクトリに展開されるだけなので、自分でビルドする必要があります。Podsディレクトリには導入した各ライブラリのプロジェクトやソースコードの他にPods.xcodeprojが作られています。Pods.xcodeprojは導入したPodがすべて含まれているプロジェクトです。Pods.xcodeprojをビルドするとすべてのライブラリがビルドされます。下記はPods.xcodeprojをiOSとSimulatorの両方で特定のディレクトリ以下にビルドするスクリプトです。xcprettyこのスクリプトでビルドした成果物はPods/Build/Release-iphoneosまたはRelease-iphonesimulatorに出力されます。このディレクトリは下記のようにEFFECTIVE_PLATFORM_NAME変数を用いて自動的に切り替わるように変数化しておきます。上記で変数化したPODS_CONFIGURATION_BUILD_DIRとPODS_ROOTを用いて各ライブラリを手作業でリンクします。下記のxcconfigファイルは本体アプリケーションのビルド設定の抜粋です。Firebaseはこのアプリケーションが動的リンクするフレームワークに静的リンクされるので、アプリケーションには直接リンクせず参照の設定があるだけになっています。Frameworkです。このフレームワークにFirebaseを静的リンクしています。Firebaseをアプリケーションにもリンクしてしまうと、シンボルの重複が発生します。Frameworkは実行時にリンクされるのでアプリケーション本体にバンドルされてなければなりません。Phaseで実行してアプリケーションバンドルにコピーします。donefiリソースのコピーCocoaPodsはリソースもサポートしているので、リソースをコピーする必要があるライブラリがあるかもしれません。Phaseで下記のようなスクリプトを実行して解決します。"${BUILT_PRODUCTS_DIR}/${EXECUTABLE_FOLDER_PATH}/"おわりにこのようにすることで、CocoaPodsで導入したライブラリであっても、Carthageのようにビルド済みライブラリとして取り扱えます。プロジェクトにCocoaPods関連の設定が入らないので、.xcodeprojをクリーンに保てることや、ビルド済みライブラリとして取り回せるのでクリーンビルドのさいもライブラリまですべてビルドされてしまうことはありません。CocoaPodsが自動設定していたものを手作業で設定していく手間は増えますが、変更管理もできるようになるので、デメリットばかりでもありません。副次的なメリットとして、ライブラリのキャッシュのコントロールがやりやすくなりました。ビルド済みライブラリをアーカイブすればいいので、CIではライブラリのビルドする回数を大幅に削減できた上、現在は手元の環境もビルド済みライブラリをキャッシュからダウンロードするだけになり、手元でライブラリをビルドするということがほとんど必要なくなりました。CIやビルド済みライブラリのキャッシュについては、また別の記事で解説します。下記の記事でも少し触れています。月別アーカイブはてなブログをはじめよう!KishikawaKatsumiさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。