まえがき

「ビルド待ちすぎて頭おかしくなりそう」
そうやって消耗されてませんか？自分もそうでした。

でも巷にはXcodeでのビルド時間を削減・短縮する様々な方法がシェアされております。
そこで、実際に自分が開発しているProjectに対してそれらの方法をちゃんと適用して、どの程度効果があったかを実測値とともに記しておければと思い執筆しました。

ビルド時間が長くて作業に集中できないよっていう方
よく何％削減とかいうけれど本当に実測値でみても効果あるの？と疑問を抱いている方

の参考になれば幸いです。

本記事でも、改善方法についての解説は行なっておりますが、先人様方の記事の方がより詳細に記されているため、そちらも合わせてご参考にしていただければと思います。同時に、今回の効果測定でも下記記事は大変参考になりました。ありがとうございます

@you_matz さん： Xcode8でビルドが遅すぎるのを解消した件（Swift パフォーマンス改善）
@manshiro さん： Xcode8でのSwiftのビルドが遅い
Stack Overflow： ios - XCode 8.0 Swift 3.0 slow indexing and building

検証環境

今回のビルド時間削減を行う前の状態のスペックを晒しておきます。
詳細な設定値などは、個々のビルド短縮方法の紹介とともに記します。

Swift3.1と一部Objective-Cからなるそれなりに巨大なプロジェクトファイル(数百〜数千ファイル規模)
- 過度にnil合体演算子を使わない、lazy varは基本的に使わない方針
- 割と厳密にファイルアクセス修飾子(finalやprivate)を設定している
- Cocoapods & Carthage使用
  - 今の時点でpodからCarthageに移行できるframeworkは無い
- 大人数で開発しているので1秒遅いだけでも積み重なってかなり変わってくる
ビルドにはXcode 8.3.3/iOS10.3.1 Simulatorを使用
- Build Only DeviceだとSimulatorに比べてビルド時間が少し多くかかるため
PCはMacBook Pro 15inch （2013）を使用
検証は、Xcodeを再起動し、Derived Dataファイルを削除し、念のためClean(Cmd + Shift + Opt + K)してからBuildした際の時間を比較して実施
純粋なビルド時間を計測するため、他のジョブは基本的に閉じた状態で実施
- そのため、通常時は別のジョブも動いていることを考えるともう少し時間は伸びそうに思えます

Before & After

先に簡単な結果だけ載せておきます。（一番最後に詳細な結果を載せています）
Debugビルドではビルド時間を半分以上早くすることができました
が、Release(InHouse)ビルドではあまり効果が見られなかったと言う結果になりました。

	Debugビルド	Release(InHouse)ビルド
Before	266s	384s
After	110s(58.6% )	373s(1.8% )

やったこと

それでは本題に入っていきます。下記の施策を行いました。

【番外編】不要なBuildをせずにRunする
【下準備】ビルド時間を表示できるようにする
1. Optimization Levelの見直し（Debugビルドのみ適用）
2. Build OptionsのDebug Information Formatの見直し
3. コンパイルに時間のかかるメソッドを検出してリファクタリングする
4. コンパイル時のタスク数を増やしてマルチタスクにする（結果的に変更なし）

【番外編】不要なBuildをせずにRunする

特に前回ビルドから変更もしてないのにRun(Debug)するたびに再度Buildさせてしまってたりしてませんか？
まずビルド削減施策を行う前に、自身のやり方を一度振り返って見ることをお勧めします！

RunはCmd + Rで行なっている方がほとんどかもしれませんが、ビルドせずに前回のビルドの状態でRunする方法があります。それは以下のショートカットで実現できます。
Cmd + Ctrl + R
このシチュエーションの場合は、毎回かかっているビルド時間をゼロに削減できます。
まだビルドされてない場合もダイアログが出てくれるのでBuild & Runをタップすれば通常のRunが実行されます。
知らない方、あまり使用されていない方は今一度覚えておくとよいかもしれません。

【下準備】ビルド時間を表示できるようにする

先ほどの結果はどうやって測ったの？と思う方もいらっしゃるとは思いますが、実はコマンド一発でXcodeのGUI上に表示することができます。デフォルトにしてほしいくらいです。
まずは己の現状を知るということで、まだ設定されていない方がいらっしゃいましたら、ぜひこれを機に設定して見てください。

ターミナルにて下記コマンドを実行しましょう。
defaults write com.apple.dt.Xcode ShowBuildOperationDuration YES

ビルドが成功するとSucceededの右側に表示されるようになります。

1. Optimization Levelの見直し

Build Settings > Swift Compiler > Optimization Level

Debugビルドの場合は頻繁にビルドを行うため、最適化をかけるとかえってビルド時間を増やしてしまうようです。
そのため、Noneを設定しておきましょう。おそらくデフォルトでもその設定になっているため、もし変えてしまっている方がいらしたら一度見直してみてください。
（もちろん、Releaseビルドの際は最適化が効くようにFastなどを設定しておきましょう。）

SWIFT_WHOLE_MODULE_OPTIMIZATIONフラグを有効化

この設定がDebugビルドのビルド時間を劇的に改善してくれました
設定の仕方は、Build Settingsを開き、その下の+ボタンからAdd User-Defined Settingをタップします。

そして、下記のようにKey/Valueを設定するだけです。
もちろん、ConfigurationごとにYES/NOを設定することも可能です。
SWIFT_WHOLE_MODULE_OPTIMIZATION YES

Debugビルドでは、Optimization LevelはNoneに指定しているにもかかわらず、こちらのOptimization設定をYESにするとビルド時間短縮を実現できました。（なぜこれが効いているのかは正直あまりよくわかっておりません。）
InHouse（Release）ビルドでは、もともとOptimization Levelがwhole module optimizationになっているからか、全く効果がありませんでした

ただ、ビルドログを眺めているとわかったのですが、フラグ未設定時は一ファイルごとにコンパイルログが吐かれていたログが、下記のようなログしか出なくなりました。全体モジュール最適化が効いているようです。

また、この設定を行うとフルビルドの時間は改善されたとしても、差分ビルドの時間がフルビルドと同じくらいかかるようになるといった書き込みを見ましたが、当方の環境では差分ビルドの時間は設定前と体感的にほとんど変わらず、フルビルドよりも短い時間で行えています。むしろ今までは差分ビルドの際も数分かかっていた場合があったので、もろもろ鑑みると大いに効果がありそうです。
他にも、debug時のpoコマンドを使うとクラッシュするなどの記事もありましたが、自分の環境では問題なく使えています。

2. Build OptionsのDebug Information Formatの見直し

こちらも、Optimization Level同様で最近のXcodeでProjectを作成するとデフォルトで設定されているため、効果がない方もいらっしゃるとは思いますが、古くからのProjectファイルを編集している方は一度見直してみると良いかもしれません。

Build Settings > Build Options > Debug Information Format
にはDWARF with dSYM FileおよびDWARFが設定できます。

dSYMファイルを必要としないConfigurationの際は、DWARFにしてみましょう。
dSYMはCrashファイルの解析に必要となるため、クラッシュ検知などに利用されている場合は設定変更できないのでご注意ください。当方では、Debugビルドの時のみdSYMが不要なため、DWARFへと変更しました。

3. コンパイルに時間のかかるメソッドを検出してリファクタリングする

Build Time Analyzer for Xcode
というファイルごとのビルド時間を計測してくれるツールがあります。

非常に便利なツールなので一度は使っていただきたいですが、そのツールを毎回のデバッグで使うにはちょっと荷が重かったりするため、もっとお手軽に利用できるのがこちらのフラグを設定する方法です。
Build Settings > Other Swift Flagsに以下を定義します。
-Xfrontend -warn-long-function-bodies=100

こちらでは、メソッド単位でビルド時間が長くかかっているものに対してwarningを表示できます。
/Users/ruwatana/Hoge/ViewController.swift:100:10: Instance method 'hoge()' took 1000ms to type-check (limit: 100ms)

ひとまず100ms以上かかるメソッドを警告表示させ、下記ページを参考に警告が出なくなるまでリファクタリングを行いました。主にCGFloatの型判定あたりが無駄に時間がかかっていました。
Regarding Swift build time optimizations

ただし、これに関しては当プロジェクトがある程度コーディング規約として対策がなされていたということもあり、体感するほどの改善はほとんど見込めませんでした。（1メソッドで最大数秒の改善程度）
ただ、こちらも知らなかった方は、頭のどこかに入れておくとよいかもしれません。

4. コンパイル時のタスク数を増やしてマルチタスクにする

結論から述べますが、こちらは効果がありませんでした

他の記事などでは、Xcodeはデフォルトでは1つのタスク上でしかビルドは実行されないのでタスク実行数を複数に変えるとビルド時間が早くなると書いてあったりしますが、未設定の状態で、実際のビルドの動きをみているとMacBook Pro 15inchでは4〜8個くらいのタスクが動的に動いていました。
つまり、元から最適化されているといえそうです

ちなみに、タスク実行数の変更はターミナルにて下記コマンドを入力すると行えます。
ためしに、当方の4コアのCPUを搭載したPCで4に設定して試してみましたが、やはり元の方が早く、少し遅くなったという結果になりました。

Terminal

defaults write com.apple.dt.Xcode IDEBuildOperationMaxNumberOfConcurrentCompileTasks 4

間違えて設定されてしまっている場合は、下記コマンドで消すこともできるので、一度設定を見直して見るのが良いと思います！