図書館？静的？動的？またはフレームワーク？別のプロジェクト内のプロジェクト
既存のiOSアプリがあり、テストを簡単にするために、別のプロジェクトとして開発してきた大量のコードを追加したい。新しいチャンクは基本的に、さまざまな共有サービスなどに画像を保存することを扱います。その共有コードは多くのテストと将来の更新を必要とするため、既存のアプリにそのコードチャンクを組み込む最良の方法は疑問に思いました。
静的ライブラリ、動的ライブラリ、またはフレームワークのどちらなのかわかりません。正直、違いは何なのか、Xcodeでどのように設定して取得するのかはよくわかりません。
私が知っているのは、共有コード用に個別のテストおよび更新アプリを保持し、メインアプリで使用する必要があることです。
まず、いくつかの一般的な定義（iOSに固有）：
静的ライブラリ-コンパイル時にリンクされるコードの単位で、変更されません。
ただし、iOS静的ライブラリは、イメージ/アセット（コードのみ）を含めることを許可されていませんnot。ただし、media bundleを使用すると、この課題を回避できます。
より良い、より正式な定義は、ウィキペディアで見つけることができます ここ 。
動的ライブラリ-may変更する実行時にリンクされるコードまたはアセット、あるいはその両方。
ただし、AppleのみがiOS用の動的ライブラリを作成できます。アプリを拒否するため、これらを作成することはできません。 （確認およびそのような理由については this other SO postを参照してください）。
Software Framework-タスクを実行するコンパイル済みのコードセット...したがって、実際にはstatic frameworkまたはdynamic framework。これらは通常、上記のコンパイルされたバージョンです。
詳細については、 Wiki on Software Framework を参照してください。
したがって、iOSでの唯一のオプションは、基本的に静的ライブラリまたは静的フレームワークを使用することです（主な違いは、静的フレームワークがコンパイル済み.aファイルとして配布されるのに対して、静的ライブラリは単にサブプロジェクト-すべてのコードを見ることができます-最初にコンパイルされ、その結果として.aファイルがプロジェクトによって依存関係として使用されます）。
これらの用語が明確になったので、iOS用の静的ライブラリのセットアップとメディアバンドルのサポートはそれほど難しくなく、その方法については多くのチュートリアルがあります。私は個人的にこれをお勧めします：
https://github.com/jverkoey/iOS-Framework
これは非常に簡単なガイドであり、「偽の静的ライブラリ」を処理するというデメリットはありません...詳細については、こちらをご覧ください...
静的ライブラリを作成したら、Git内でsubmoduleとして含めるだけで、さまざまなプロジェクトで使用できます。
幸運を。
編集
私の知る限り、プロジェクト内のsubprojectに関して、これを正しく動作/コンパイルさせるには、基本的にサブフレームが最初にコンパイルされるコンパイルチェーンを設定する必要があります。プロジェクトが依存関係として使用する.aファイル。
これについて説明する別の便利なチュートリアルを次に示します。
http://www.cocoanetics.com/2011/12/sub-projects-in-xcode/
EDIT 2
IOS 8では、Appleにより、開発者は動的フレームワークを作成できるようになりました！ （注：動的なフレームワークを含めるには、アプリにiOS 8の最小ターゲットが必要です...バックポーティングは許可されていません。）
これは、新しいプロジェクトテンプレートとして追加されました。 Xcode 6.1では、これは次の場所にあります。
New Project -> iOS -> Framework & Library -> Cocoa Touch Framework
ライブラリとフレームワーク
InversionOfControlのMartin Fowler
libraryは、基本的には呼び出せる関数のセットであり、最近では通常クラスに編成されています。各呼び出しはいくつかの作業を行い、制御をクライアントに返します。
frameworkは、より多くの動作が組み込まれたいくつかの抽象的な設計を具体化します。それを使用するには、サブクラス化するか、独自のクラスをプラグインすることにより、フレームワークのさまざまな場所に動作を挿入する必要があります。フレームワークのコードは、これらのポイントでコードを呼び出します。プログラムの主な制御は逆になり、あなたから離れてフレームワークに移動します。 （制御の反転）
IOSのライブラリとフレームワーク
libraryは、1つ以上のアーキテクチャ用にコンパイルされたリソースとコード自体のコレクションです。 *.oファイル（Mach-Oオブジェクトファイル）で構成されます。
static libraries (*.a)-アプリが使用するコードは、コンパイル時間の間にstatic linkerによって生成された実行可能ファイルにコピーされます。
Xcode 9.0の時点で、静的Swiftライブラリがサポートされるようになりました。
バイナリとヘッダーを別々に出荷する必要があるという一般的な問題。
✓長所：
- 静的ライブラリはアプリに存在し、正しいバージョンを持っていることが保証されています。
- ライブラリの更新でアプリを最新の状態に保つ必要はありません。
- ライブラリ呼び出しのパフォーマンスが向上しました。
✕短所：
- 膨らんだアプリのサイズ。
- 肥大化したアプリの実行可能性により、起動時間が低下します。
- 単一の関数を使用する場合でも、ライブラリ全体をコピーする必要があります。
Dynamic libraries (*.dylib)は、loadまたはruntimeにあるアプリの実行可能ファイルに動的にリンクされているが、コピーされないという意味で、static librariesとは異なります。その結果、実行可能ファイルは小さくなり、必要な場合にのみコードがロードされるため、起動時間が通常より速くなります。
すべてのiOSおよびmacOSsystemライブラリは動的です。したがって、アプリは、Appleが新しいビルドを作成して出荷せずに標準ライブラリフレームワークに加える将来の改善の恩恵を受けます。
✓長所：
- アプリを再コンパイルせずにライブラリを改善できます。システムライブラリで特に便利です。
- アプリケーション間で共有されるため、ディスク容量が少なくなります。
- 実行時にオンデマンドでロードされるため、起動時間が短縮されます。
- 分割ロード：単一の機能を使用する場合、ライブラリ全体をロードする必要はありません。
✕短所：
- ライブラリ内で何かが変更されると、プログラムが破損する可能性があります。
- ライブラリ関数はアプリケーション実行可能ファイルの外部にあるため、ライブラリ関数の呼び出しが遅くなります。
bundle は、サブディレクトリが内部にあるファイルディレクトリです。 iOSでは、bundlesは、関連するファイルを1つのパッケージ（たとえば、イメージ、ニブ、またはコンパイル済みコード）にまとめて簡単に配布するのに役立ちます。システムはそれを1つのファイルとして扱い、内部構造を知らなくてもバンドルリソースにアクセスできます。
libraryには、ヘッダー、ローカライズファイル、画像、ドキュメント、使用例などの追加リソースもあります。これらすべてを1つのbundleにまとめることができます。この名前はframework (*.framework)です。
Static frameworksには、そのリソースと共にパッケージ化されたstatic libraryが含まれます。
Dynamic frameworksには、そのリソースとともにdynamic libraryが含まれます。それに加えて、dynamic frameworksは同じフレームワークに同じdynamic libraryの異なるバージョンを便利に含めることができます！
Embedded framework：
Embedded frameworkはDynamic frameworkであり、アプリのサンドボックス内に配置され、そのアプリでのみ使用可能です。このタイプは、最初に extension で作成され、共通のコードとリソースを共有します。 展開ターゲットがiOS 8以降の場合に利用可能です。Embedded frameworkは、アプリケーションターゲット内に埋め込まれたStatic frameworkです。 続きを読む
Umbrella framework[集計対象] は、他のフレームワーク（別名Nested Framework）を含むフレームワークバンドルです。アンブレラフレームワークを作成することは可能ですが、ほとんどの開発者にとってはそうすることはunnecessaryであり、推奨されません。 [公式ドキュメント]
Fake Framework-偽のフレームワークは、バンドルをフレームワークに「変換」する一般的な手法ですが、実際にはbundleです。たとえば、独自のフレームワークを作成し、内部でサードパーティライブラリを使用する場合、コードとサードパーティライブラリを一緒に（1つのフレームワークとして）出荷できます。実現の1つ 偽のフレームワーク 。
Universal Framework（別名Fat Framework） [集計対象] -Static frameworkは、Simulatorの2つのバージョンの.frameworkファイルを含みます。つまり、x86_64、i386、およびDeviceの場合はarmv7、armv7s、arm64です。本当に2つのバージョンしか必要ない場合、またはライブラリのソースコードがプライベートに保たれている場合、これはあなたにとって完全に素晴らしいソリューションかもしれません。ただし、事前に作成されたライブラリのバージョンを維持するタスク（およびそれらを1つのファイルにまとめる追加の作業）が残っています。
Cross-Project References（別名Project inside another project）を使用できます [約] の代わりにUniversal Frameworkこのアプローチを使用すると、現在のビルド構成（デバッグ、リリースなど）を使用して、アプリの残りの部分でバイナリを自動的にビルドし、個別にバイナリ（各バージョンが特定の環境/構成用に構築された場合）。
XCode 4では、Workspaces[約] は、XCode 3s cross-project referencesの機能に取って代わります
静的ライブラリを構築して使用する方法：
Swiftコンシューマー-> Swift静的ライブラリー
Swiftコンシューマー-> Objective-C静的ライブラリー
Objective-Cコンシューマー-> Swift静的ライブラリー
Objective-Cコンシューマ-> Objective-C静的ライブラリ
静的フレームワークを構築して使用する方法：
Swiftコンシューマー-> Swift静的フレームワーク
Swiftコンシューマ-> Objective-C静的フレームワーク
Objective-Cコンシューマー-> Swift静的フレームワーク
Objective-Cコンシューマ-> Objective-Cフレームワークライブラリ
リンク集
CocoaPods（ http://guides.cocoapods.org/making/private-cocoapods.html#1.-create-a-private-spec-repo ）の.podspecファイルを作成して使用することもできますそれはあなたのプライベートポッドであり、外の世界には見えないという唯一の違いを持つ他のポッドと同じです（ポッドがCoreDataモデルを作成する必要がある場合はどうなるかわかりませんが、そうではありません、私は理解しています）。