脱fat pbxproj
え、XcodeGen使ってないんですか？
終
制作・著作
━━━━━
ⓃⒽⓀ
え、最近流行りのマルチモジュール構成にしていないんですか？
終
制作・著作
━━━━━
ⓃⒽⓀ
さて、この先まで読んでくれた人のために記事を書いていこうと思います。
まず、なぜ上記の構成にしていないのかについて紹介しようと思います。それはできるだけ標準のビルド構成とかけ離したくないからというのが理由です。
標準のビルド構成と離せば離すほど、何か不具合が起きた時に対応する負荷が増えてしまいます。もし、チーム内にそういった技術に精通している人がいればまだ何とかなりますがそういった人が抜けてしまうと負債にならないかといった点も考慮してあまり複雑な構成にはしたくないかなというのが自論です。
pbxprojってなによ？
アプリを作成するときは、 .xcodeprojファイルを開くと思うのですが、実際にはディレクトリになっておりその中に存在するファイルになります。.pbxprojファイルには、Xcode上で設定しているような内容が書き込まれています。
よくこれがコンフリクトするのが多いかと思います。
では実際にこれにはどういった内容が書いてあるのでしょうか？
本記事ではこの内容について深く解説しないのでこちらの記事を参考にしてください。
ダイエット方法
プロジェクトが巨大になっていくとファイルであったり設定項目は右肩上がりに増えていくと思います。ではいったいどのようにしてこのファイルの中身を減らしていくことができるでしょうか？
個人的に推奨している方法は下記です
- ビルド対象をGroupからFolderにする
- SPMの定義をPackage.swiftへと移す
ビルド対象をGroupからFolderにする
Xcode16からの機能ですね。
これはかなり削れます。今までは一つ一つのファイルについて記載があったのですが、それがディレクトリ単位になるのでかなり楽です。そしてコンフリクトもほとんどなくなります。革命ですね。
SPMの定義をPackage.swiftへと移す
これに関していうとあれ？マルチモジュール構成にはしないっていってたやんけとつっこまれると思います。もちろんその通りなのですが、pointfreeのisowordsに代表されるようなマルチモジュール構成の考え方は非常に優れていると思っており、ここで紹介しているアイデアはその考えをもとにしつつ基本構成とかけ離れ過ぎないというのが個人的におすすめなポイントです。
この方法では、SPMに関する記載をPackage.swiftへと移せるのがいいですね。GUIでなにを追加している確認したい人もいるかと思いますが、CocoaPodsやCarthageに慣れていた人からすると、Package.swiftで管理したくなるのかなと思います。
余談
Package.resolvedをどこに持たせるかというのも上記だと一つのポイントにはなります。通常の構成だと、xcodeprojかxcworkspaceの下にPackage.resolvedが持ちます。ただ、上記の場合ですとPackage.resolvedをDependencies配下におくことができます。
Xcodeは上記のような構成にした場合に
- Package.swiftがある階層にPackage.resolvedがあればそれを読む
- xcodeprojかxcworkspaceの下にPackage.resolvedがある場合にはそれを読む
- Package.resolvedがない場合には、xcodeprojかxcworkspaceの下にPackage.resolvedを作成する
という順番に挙動が変わるので1になるようにPackage.resolvedをおくのがいいです。
※ ただし、Xcode16の場合。Xcode15だと1は実行されず、2と3のみで処理が進む。
まとめ
とりあえずXcode16にあげようぜ
Discussion