Xcodeワークスペースとネストされたプロジェクト
Xcodeワークスペースを使用して、相互に依存関係のあるプロジェクトを整理する方法がわかりません。たとえば、多くの開発者が次のようなワークスペース構造を作成しているのを目にします。
ワークスペース |-アプリ |-共通ライブラリ |-別の共通ライブラリ
これにはどのようなメリットがありますか？誰かが「アプリ」プロジェクトを直接開いた場合、実際にアプリをビルドすることはできませんか？彼らは、必要な依存関係を持つワークスペースが存在することを認識しなければなりません。
より良いアプローチは、次のようなネストされたプロジェクトを使用することであるように私には思えます。
アプリ |-ライブラリ | |-共通ライブラリ | |-別の共通ライブラリ
その場合、ビルドできないプロジェクトは存在しません。また、Gitのサブモジュールの考え方とより一致しているようです。
ワークスペースで私が目にする唯一の用途は、相互に依存しない一般的なプロジェクトをグループ化することです。何か足りないかもしれないので、他の人の考えを聞いてみたいです。
プロジェクトの独立性を維持しながらプロジェクトを結合したい場合は、ワークスペースを使用します。
私がワークスペースを使用する例は、非常に単純なものからより複雑なものへと進む一連のチュートリアルプロジェクトです。各プロジェクトはスタンドアロンプロジェクトとして機能できますが、ワークスペースにグループ化すると、プロジェクト全体を整理するのに役立ちます。
別の例では、クライアント用に開発されたアプリがあります。このアプリは、プロジェクト全体でスタンドアロンアプリとモジュールの両方として機能します。独立したプロジェクトは、スタンドアロンアプリを構築できます。もう1つのアプリは、2つのプロジェクトを含むワークスペースを使用します。アプリのモジュールバージョンは特別なスキームから構築されており、この結合されたアプリはワークスペースを使用せずに構築されません。
上記の2つの状況での1つの工夫は、ビルドフォルダーが保存される場所です。 Xcode設定を変更して、ビルド製品をチュートリアルプロジェクトのグループの一意のフォルダーに配置し、他のアプリセットアップ内のモジュールに共通のビルドフォルダーを使用する必要があります。
他の状況では、プロジェクトが埋め込まれたプロジェクトがたくさんあります。このような状況では、ライブラリプロジェクトは安定しています。私は図書館プロジェクトのさらなる開発を試みていないので、それらはプロジェクトの単なる別のリソースです。プロジェクトリソースのファイルシステム構成がXcodeプロジェクトの構成をある程度反映している場合は、作業が簡単になります。したがって、これらのライブラリプロジェクトは、メインプロジェクトのファイル階層にコピーされます。ライブラリを開発して複数のプロジェクトで使用する場合は、ワークスペースを使用するのが理にかなっています。便宜上、私は頻繁に気にしません。
ワークスペースを、埋め込みプロジェクトを含むプロジェクトと組み合わせる場合もあります。
ですから、私の意見では、組み込みプロジェクトとワークスペースの両方の組織ツールには、それぞれのメリットと問題があります。特定の状況に応じて、どちらか一方（または組み合わせ）を使用することを選択します。
ネストされたプロジェクトをメインプロジェクトのフレームワークに追加したので、それらを.framework製品に「含める」ことができました。
Main
|-- Main
|-- MainTests
|-- Frameworks
| |-- CommonLibrary.xcodeproj
| |-- AnotherCommonLibrary.xcodeproj
| |-- UIKit.framework
| |-- Foundation.framework
| |-- CoreFoundation.framework
|-- Products
プロジェクトにユニバーサルフレームワークを追加するには、 Jeff Verkoeyenによるこのすばらしいチュートリアル を参照してください。最初は簡単ではありませんが、作業を続けると、コツをつかむことができます。