BAD_ACCESS

おもにiOS、ときどき変な電子工作、ガジェット話。

自前のライブラリをCocoaPodsで管理するメモ

意外とまとまっていないかったので作業しながらまとめたメモ。

CocoaPodsとは

公式:http://cocoapods.org

CocoaPodsをプロジェクトに追加する方法はこのまとめが丁寧でわかり易かった。

CocoaPodsを使ったXcodeプロジェクトの作り方(1)

CocoaPodsを使ったXcodeプロジェクトの作り方(2)

CocoaPodsを使ったXcodeプロジェクトの作り方(3)

CocoaPodsを使ったXcodeプロジェクトの作り方(4)

1.自前のライブラリをCocoaPodsに対応させる

まずはライブラリを作成しているプロジェクトのファイル構成を推奨されている形にまとめる。

公式が推奨するファイル構成

. 
├── Classes
    └── ios
    └── osx
├── Resources
├── Project
    └── Podfile
├── LICENSE
├── Readme.markdown
└── NAME.podspec//これは今からつくるファイル。

実際の構成はこんな感じ。 pod_structure

2.Pod(PodSpecファイル)の作成

自前ライブラリを作成しているプロジェクトのディレクトリにて下記のpodコマンドを実行する。

 pod spec create MyLibrary

これで先ほどのMyLibrary.podspecファイルが作成される。

3.PodSpecファイルの編集

自動作成されたPodSpecにはコメントアウトされたテンプレートが出力されるが、最終的には不必要なコメントは全て削除する。

PodSpecファイル内は必要に応じて書き換える必要がある。 今回はGithub上に作成したソースを参照する場合のPodSpecファイルの例。

Pod::Spec.new do |s|
  s.name         = "SWScrollView"
  s.version      = "0.0.1"
  s.summary      = "Scroll view like Star Wars opening crawl."
  s.license      = { :type => 'MIT', :file => 'LICENSE.txt' }
  s.homepage     = "https://github.com/somtd/SWScrollView"
  s.author       = { "SOMTD" => "matsuda-so[at]kayac.com" }
  s.source       = { :git => "https://github.com/somtd/SWScrollView.git", :tag => "0.0.1" }
  s.platform     = :ios, '5.1'
  s.requires_arc = true
  s.source_files = 'SWScrollView/**/*.{h,m}'
  s.resources    = 'SWScrollView/**/*.xib'
  s.frameworks   = 'QuartzCore'
end

今回の例では以下の2点が特殊だったので注意。

  • 自前ライブラリがQuartzCore.frameworkに依存している。
  • 自前ライブラリがxibファイルを含んでいる。

そのため、上記のPodSpecファイル上で

  s.resources    = 'SWScrollView/**/*.xib'
  s.frameworks   = 'QuartzCore'

の記述が必要となっている。

4.PodSpecファイルのチェック

PodSpecファイルを作成した後に正しく書かれているかどうかを以下のpodコマンドを実行して確認することができる。

pod spec lint MyLibrary.podspec

ただし、この場合はGithub上のPodSpecファイルに対して評価を行なっているため、まだpushしていないときなどは以下のようなエラーが返ってくる。

[!] Pod::Executable fetch origin tags/0.0.1 2>&1

fatal: Couldn't find remote ref tags/0.0.1

fatal: The remote end hung up unexpectedly

いきなりpushしたもので試せない場合は、

pod lib lint

というコマンドをプロジェクトのディレクトリで実行するとローカルのPodSpecファイルを評価してくれるので、先に試すほうがいいかもしれない。

【参考】:pod spec lint: "--local" option no longer available

うまくいくと、

MyLibrary passed validation.

と表示される。

5.DemoProjectにつくったPodをイントールしてみる。

つくったPodを自分のDemoプロジェクトにインストールして確認してみる。といっても手順は簡単。

pod_structure

同じライブラリプロジェクトのDemoプロジェクトに移動し、下記のpodコマンドを実行。

pod setup

そして直下にPodfileを作成する。

touch Podfile

そしてPodfileを下記のように書き換える。

  platform :ios, '5.1'
  pod 'MyLibrary', :path => '..'

Podfileの編集が完了したら下記のpodコマンドを実行。

pod install

成功すると同じディレクトリ配下にMyLibraryDemo.xcworkspaceが作成されるので、それを起動し、ライブラリ自体が正しく反映されていることを確認できる。

これでDemoプロジェクトからは自分のローカルのライブラリを見に行くことになるので開発を進めながらもライブラリをPodで管理することができる。

6.CocoaPods/Specsのフォーク

自前のライブラリが整ったら、いよいよGithubを使ってCocoaPods本体に取り込んでもらう準備をする。 (CocoaPods本体に取り込まなくてももちろん公開することはできるが、今回はこの手順で説明を進める)

まずはCocoaPodsの大本からSpecsというリポジトリを自分のGithubリポジトリ上にforkする必要がある。 CocoaPods/Specs

Specs Fork

おそらく下記のようなGithubリポジトリが作成されるはず https://github.com/<USER_NAME>/Specs

7.自前のライブラリをCocoaPodsにpushする(ローカルで準備)

Demoプロジェクトでも正しく動いていることを確認したら、まずは自分のプロジェクトのGithubリポジトリに変更をプッシュする。

そのときに、versionのタグをわすれずに付けておく。(付けないとpod lintしたときに怒られる)

git tag 0.0.1
git push --tags

pushしたあとに確認。

pod spec lint MyLibrary.podspec

lintの確認で問題がなければディレクトリを.cocoapods/masterに移動する。 (このディレクトリは一番最初にcocoapodsを導入したときに作られている?)

cd ~/.cocoapods/master

移動した時点でのブランチ名はmasterになっているはずなので、そこから任意のブランチに切り替える。ここではブランチ名をforkとして進める。

git checkout -b fork

このブランチに先ほどforkしたGithubリポジトリをremote addする。

git remote add MyFork https://github.com/<USER_NAME>/Specs.git

ここに新たに追加したPodSpecファイルを追加する。 追加するときにルールがあるので以下の通りに作成し、追加するようにする。

  • masterディレクトリの下にpodの名前でディレクトリをつくる。
  • podの名前ディレクトリの下にバージョン番号のディレクトリを作る。
  • そのディレクトリの下にMyLibrary.podspecファイルを追加する

8.自前のライブラリをCocoaPodsにpushする(pull requestを送る)

ディレクトリに追加したことを確認し、先ほど作成したremoteのブランチにプッシュする。

git push MyFork fork

再びGithubのforkしたレポジトリhttps://github.com/<USER_NAME>/Specsを開く。

forkしたときのブランチを選択すると自分のpushした変更が確認できる。 これをもとにCocoaPods本体、つまりmasterブランチにpull requestを送る。

select

自分がforkしたときのブランチ名を選択。

send pull request

早ければ1日以内にmergeされ取り込みが完了となる。

【参考】:CocoaPodsでPodの利用&作成のメモ

【参考】:Creating and maintaining a pod

【参考】:Sharing pod specifications with yourself and the world

【参考】:Contributing to the master repo