こんにちは！iOSエンジニアのaboyです。
弊社の＠ｃｏｓｍｅアプリ開発チームでは、「ビルドに時間がかかる」というのが課題としてあげられています。
ビルド時間が増える要因は様々ありますが、今回は改善策のひとつとして、ライブラリ管理ツールをCocoaPodsからCarthageに移行した話をご紹介します。
前提
弊社の現時点での一般的な開発マシンはMacBook Pro (Retina, 15-inch, Mid 2015)、プロセッサは2.2 GHz Intel Core i7でメモリ16GBです。
このマシンでdefaults write com.apple.dt.Xcode IDEBuildOperationMaxNumberOfConcurrentCompileTasks 4 でビルドを4並列にした状態で、フルビルドに約360sかかっていました。
Carthage移行の流れ
当然新規機能の実装や改修も行いつつ、空き時間で少しずつCarthage移行を進めました。
また、どれくらい効果があったかをチームメンバーやマネージャにも説明できるように、数字は記録しておきました。
ちょうど機能実装の案件をリリースするタイミングでこのCarthage移行もリリースに混ぜ込んでもらい、リリース前はiOSチーム総出でアプリ全体の動作確認を行いました。
アプリチームでは毎日「タ会」と称して進捗共有などを行なっているのですが、その場で「今日は◯◯秒縮まりました」と報告するとチームのみんなが拍手してくれたりするなど、みんなで盛り上げる雰囲気があったため、楽しくCarthage移行ができました。
結果
肝心の結果ですが、
360s -> 280s まで短縮しました！
移行の推移はこちらです。
基本CocoaPodsの比率に比例してクリーンビルド時間も緩やかに減少していますが、ZXingObjCをCarthage移行したタイミングで約30s一気に減っています。当然ライブラリによってコンパイル時間はまちまちなので、このように効果に差は出ます。
少しずつCarthage移行したい方は、ビルド中のログを見て、コンパイルに時間がかかっているライブラリからCarthage移行していくのが効率的です。
まだCocoaPodsあるじゃん！って感じですが、READMEにCarthage対応と書かれていなかったり、Carthageによるインストールがうまくいかなかったライブラリは、CocoaPodsのままにしてあります。この残りのライブラリのコンパイル時間が計10sぐらいでしたので、コスパを考えて今回は見送ることにしました。
つまづいたところ
Alamofire利用箇所でクラッシュした
Carthage移行の途中で、Alamofireの一部の処理で Swift fatal error: call of deleted method になりアプリがクラッシュする現象にぶつかりました。(なおこちらの現象が見つかったため念のため全画面を動作確認することになりました)
原因は、CocoaPodsで入れていたライブラリが依存していたAlamofireと、Carthage移行したAlamofire(正確にはAlamofireNetworkIndicator)のバージョンが違っていて、プロジェクトのコードはCocoaPods経由で入ったAlamofireを参照していたためでした。
Alamofireに依存していたライブラリは全て弊社で作ったものだったため、全てCarthage対応し、Carthage経由で入れるようにして解決しました。
iTunesConnectアップロード時、info.plistにプライバシーの記述がない！と怒られた
Carthage移行の際にFacebookSDKのバージョンが上がってしまったことで、新たにbluetoothを使う処理が追加されており、それに気づかずアップロードしようとしたためでした。
これに関してはCocoaPodsで入れていたバージョンと同じものをCarthage経由では入れられなかったため、素直にCocoaPods経由に戻しました。。。
おわりに
いかがでしたでしょうか。
ライブラリ管理ツールをCocoaPodsからCarthageに移行しただけで約80s短縮できました。
当プロジェクトにおけるリアルな数字ですので、参考にしていただければ幸いです。
また、当初はdynamic frameworksが増えることによるアプリケーション起動時間の増加を懸念していたので、起動時間を計測したのですが、そこまで増えることはありませんでした。
今回は改善策のひとつとしてCarthage移行をご紹介しましたが、アプリチームは今後もアプリ開発の生産性向上に向けて取り組んでまいります！
