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 によるすばらしいチュートリアルを参照してください。最初は簡単ではありませんが、続けていくとコツがつかめます。