Xcodeワークスペースとネストされたプロジェクト

Question

Xcodeワークスペースを使用して相互に依存関係のあるプロジェクトを整理するのはわかりません。たとえば、多くの開発者が次のようなワークスペース構造を作成することがわかります。

 
Workspace 
|-- App 
|-- A Common Library 
|-- Another Common Library 

これはどのような利点がありますか？誰かが "App"プロジェクトを直接開いても、実際にアプリケーションをビルドできないでしょうか？彼らは、必要な依存関係を持つワークスペースが存在することを認識しなければなりません。

より良いアプローチは、このようなネストされたプロジェクトを使用することであるように私には思える：

 
App 
|-- Libraries 
| |-- A Common Library 
| |-- Another Common Library 

その後何のプロジェクトをビルドすることができないということがありません。 Gitのサブモジュールの考え方に沿っているようにも見えます。

私がワークスペースで見る唯一の用途は、互いに依存関係のない共通プロジェクトをグループ化することです。私は何かを見逃しているかもしれないので、これに関する他の人の考えを聞きたいです。

Answer 1

プロジェクトを結合してプロジェクトの独立性を維持したい場合は、ワークスペースを使用します。

私がワークスペースを使用する例は、非常に単純なものからより複雑なものに進む一連のチュートリアルプロジェクトです。各プロジェクトはスタンドアロンプ​​ロジェクトとして機能することができますが、ワークスペース内でそれらをグループ化すると、プロジェクト全体の構成に役立ちます。

別の例として、私はクライアント用に開発されたアプリを持っています。このアプリは、スタンドアロンアプリとプロジェクト全体のモジュールとして機能します。独立したプロジェクトは、スタンドアロンのアプリケーションを構築することができます。他のアプリは、2つのプロジェクトを含むワークスペースを使用します。アプリケーションのモジュールバージョンは特別なスキームから構築され、この結合されたアプリケーションはワークスペースを使用せずにビルドされません。

上記の2つの状況の1つは、ビルドフォルダが格納されているところです。私はチュートリアルプロジェクトのグループのためのユニークなフォルダにビルド製品を置くXcodeの設定を変更する必要があります、他のアプリケーションの設定内のモジュールのための共通のビルドフォルダを使用してください。

他の状況では、私は埋め込まれたプロジェクトでたくさんのプロジェクトを持っています。このような状況では、図書館プロジェクトは安定しています。私は図書館プロジェクトのさらなる開発を試みていないので、それらはプロジェクトのもう一つのリソースです。プロジェクトリソースの私のファイルシステム構成が私のXcodeプロジェクトの構成を幾分反映しているところで作業するほうが簡単です。したがって、これらのライブラリプロジェクトはメインプロジェクトのファイル階層にコピーされます。ライブラリを開発して複数のプロジェクトで使用している場合は、ワークスペースを使用するのが理にかなっています。便宜のため、私はしばしば気にしません。

私は、ワークスペースと組み込みプロジェクトを含むプロジェクトを組み合わせることさえできます。

私の意見では、組織ツール、組み込みプロジェクト、およびワークスペースの両方にメリットと問題があります。私は、特定の状況に応じて、どちらか一方（または組み合わせ）を使用することを選択します。

Answer 2

メインプロジェクトのフレームワークにネストされたプロジェクトを追加したので、それらを.framework製品に含めることができました。

Main 
|-- Main 
|-- MainTests 
|-- Frameworks 
| |-- CommonLibrary.xcodeproj 
| |-- AnotherCommonLibrary.xcodeproj 
| |-- UIKit.framework 
| |-- Foundation.framework 
| |-- CoreFoundation.framework 
|-- Products 

は、プロジェクトにユニバーサルフレームワークを追加するためのthis Great Tutorial by Jeff Verkoeyenを参照してください。最初は簡単ではありませんが、それに取り組んでいれば、あなたはそれを掴むことができます。