既存のiOSアプリがあり、テストを簡単にするために、別のプロジェクトとして開発しているコードの大きなチャンクを追加したいと思います。新しいチャンクは基本的に、さまざまな共有サービスなどへの画像の保存を扱います。その共有コードには多くのテストと将来の更新が必要なため、そのコードチャンクを既存のアプリに組み込むための最良の方法は何かと考えていました。
静的ライブラリ、ダイナミックライブラリ、フレームワークのどれであるかはわかりません。正直なところ、違いが何であるか、Xcodeでどのように設定するかはわかりません。
私が知っているのは、共有コード用に個別のテストおよび更新アプリを保持し、メインアプリにそれを使用させる必要がある/したいということだけです。
まず、いくつかの一般的な定義（iOSに固有）：
静的ライブラリ-コンパイル時にリンクされるコードの単位で、変更されません。
ただし、iOS静的ライブラリに画像/アセットを含めることは許可されていません（コードのみ）。ただし、メディアバンドルを使用することで、この課題を回避できます。
より良い、より正式な定義は、ウィキペディアのここにあります。
ダイナミックライブラリ-実行時にリンクされるコードやアセットの単位で、変更される可能性があります。
ただし、iOS用のダイナミックライブラリを作成できるのはAppleだけです。これらを作成することは許可されていません。これにより、アプリが拒否されます。（そのような確認と理由については、この他のSO投稿を参照してください）。
ソフトウェアフレームワーク-タスクを実行するコードのコンパイル済みセット...したがって、実際には静的フレームワークまたは動的フレームワークを使用できます。これらは通常、上記のコンパイル済みバージョンにすぎません。
詳細については、ソフトウェアフレームワークに関するWikiを参照してください。
したがって、iOSでは、基本的に静的ライブラリまたは静的フレームワークを使用するしかありません（主な違いは、静的フレームワークがコンパイル済み.aファイルとして最も頻繁に配布されるのに対し、静的ライブラリは単にサブプロジェクトとして含まれる場合があることです。すべてのコード-最初にコンパイルされ、その結果.aのファイルがプロジェクトによって依存関係として使用されます）。
これらの用語が明確になったので、静的ライブラリをセットアップし、iOS用のメディアバンドルをサポートすることはそれほど難しくありません。その方法については、多くのチュートリアルがあります。私は個人的にこれをお勧めします：
https://github.com/jverkoey/iOS-フレームワーク
これは非常にわかりやすいガイドであり、「偽の静的ライブラリ」を扱うという欠点はありません...詳細についてはチェックしてください...
静的ライブラリを作成したら、それをGit内のサブモジュールとして含めて、さまざまなプロジェクトで使用するのと同じくらい簡単です。
幸運を。
編集
プロジェクト内のサブプロジェクトに関しては、私が知る限り、これを正しく機能/コンパイルするには、基本的に、サブプロジェクトが最初にコンパイルされるコンパイルチェーンを設定する必要があります。これにより.a、依存関係として使用される静的フレームワークファイルが作成されます。プロジェクトによって。
これについて説明している別の便利なチュートリアルは次のとおりです。
http://www.cocoanetics.com/2011/12/sub-projects-in-xcode/
編集2
iOS 8以降、Appleは開発者が動的フレームワークを作成できるようになりました。（注：動的フレームワークを含めるには、アプリにiOS 8の最小ターゲットが必要です...バックポートは許可されていません。）
これは、新しいプロジェクトテンプレートとして追加されました。Xcode 6.1では、これは次の場所にあります。
New Project -> iOS -> Framework & Library -> Cocoa Touch Framework
Mach-Oファイル形式（Mach Object- .o）
iOSの世界では、すべてのソースファイルがオブジェクトファイルに変換されます。ABI [About] Mach-Oファイル[About]は、最終的な実行可能バンドル（アプリケーション、フレームワーク）、ファイル（ライブラリ）にパッケージ化され、その動作はMach-O type[About ]
Packageそれ自体をファイルとして振る舞うディレクトリです- opaque file。これは、ユーザーエクスペリエンスのために作成されており、プログラムの予期しない動作を引き起こす可能性のある内部構造への変更を複雑にします。パッケージはで、Document Packageまたはで使用されBundleます。Show Package ContentsFinderで使用できます
Bundleは、バイナリ（実行可能コード）とそのコードのリソース（画像、nibs ... Assets.carファイル[About]など）を整理するための特定の構造を持つディレクトリです。バンドルにはInfo.plist[About]ファイルが含まれています。バンドルは、開発者の経験のために作成されました。パッケージ化も可能です。バンドルにはいくつかの種類があります。
application bundle-Application targetframework bundleそしてversioned bundleサブタイプとして-Framework Targetloadable bundle（別名plug-in bundle）-'...バンドル'（UIテストバンドル、ユニットテストバンドル）-実行時にロードできます。.bundleMacOSの拡張機能XPC Service-クロスプロセス通信は一種のプロセス間通信（IPC）です。別のプロセス（launchdルートプロセスで管理）のモジュールとして使用できます[概要]dSYM[About]バンドル）Application- .ipa、.app[About] ----packaged application bundle起動可能なプログラム。
Application extension[バージョン情報] -iOSv8から-ユーザーが他のアプリケーションと対話するときに利用できるアプリケーションの機能を拡張します。App extensionバンドルはの一部ですContaining appが、独自のサンドボックス（プロセッサ、メモリ...）で実行されるため、使用しようとするアプリapp extensionはと呼ばれHost Appます。拡張アプリの種類：
共通のコードとリソースを共有します。展開対象がiOS8以降の場合に利用できます。
Tests-packaged loadable bundleこれはバイナリをテストするために使用されます。プラグインアーキテクチャにより、新しい機能（テストケース）を個別のモジュールとして既存のバイナリに追加できます
ライブラリとフレームワーク
InversionOfControlのMartinFowler
ライブラリは基本的に、呼び出すことができる関数のセットであり、最近では通常、クラスに編成されています。各呼び出しはいくつかの作業を行い、クライアントに制御を返します。
フレームワークは、より多くの動作が組み込まれた抽象的なデザインを具体化します。それを使用するには、サブクラス化または独自のクラスのプラグインによって、フレームワークのさまざまな場所に動作を挿入する必要があります。フレームワークのコードは、これらのポイントでコードを呼び出します。プログラムのメインコントロールが逆になり、フレームワークに移動します。この現象は制御の反転です（ハリウッドの原則としても知られています-「私たちに電話しないでください、私たちはあなたに電話します」
iOSのライブラリとフレームワーク
それらはあなたが解決するのを助けることができます：モジュール性、再利用、カプセル化、ビルド時間の改善
Library1つまたは複数のアーキテクチャ用にコンパイルされたMach-Oオブジェクトファイル[静的または動的をチェック]のコレクションです。
Static library- .a（別名静的アーカイブライブラリ、静的リンク共有ライブラリ[doc] ）-コンパイル時に静的リンカーをアプリケーションに追加すると、ライブラリのオブジェクトファイルがマージされ、アプリケーションオブジェクトファイルと一緒に1つの実行可能ファイルにパッケージ化されます。ファイル。欠点は、出力ファイルが大きいことです
Xcode 9.0から、Swift静的ライブラリがサポートされます。
Dynamic library- .dylib（別名ダイナミック共有ライブラリ、共有オブジェクト、ダイナミックリンクライブラリ[doc]）は、ロード時または実行時にアプリの実行可能ファイルと動的にリンクされますが、アプリにコピーされません。実際には、アプリのパッケージにはファイルを含むFrameworksフォルダーが含まれます。すべてのiOSおよびmacOSシステムライブラリはです。欠点は、すべてのダイナミックライブラリをコピーしてリンクする必要があるため、起動時間が遅いことです。.dylibdynamic
Text-based stub library- .tbd[About]dynamic library 、ターゲットデバイス上にあるテキストスタブです。結果として、ダイナミックライブラリをバンドルにパッケージ化しないでください。サイズ効果があります。
Frameworkaka-はbinary framework（開発者がヘッダーとリソースを簡単に確認できるようにするため）、コンパイルされたライブラリ、ヘッダーファイル、およびリソースを含みます。.frameworknot packaged framework bundlestatic or dynamic
Static frameworkstatic libraryそのリソースと一緒にパッケージ化されたものが含まれています。
Dynamic framework別名Embedded framework-iOSv8から-dynamic libraryとリソースが含まれています。それに加えて、ダイナミックフレームワークは単一のバンドルに同じダイナミックライブラリの異なるバージョンを含めることができます（versioned bundle）。でもEmbedded framework使用されますApp Extension
Umbrella framework [集約ターゲット]は、他のフレームワークを含むフレームワークです。iOSでは公式にサポートされていため、開発者がそれらを作成することはお勧めしません[公式ドキュメント]。実際には、それはサブフレームワーク（またはネストされたフレームワーク）のセットです。依存関係を持つフレームワークを作成する場合、コンシューマー（アプリなど）は、フレームワークとともにこの依存関係をプロジェクトに追加する責任があります。開発者として、この義務を消費者からあなたの義務に移す方法を見つけようとするのは自然なことです。結果として、それUmbrella frameworkは救済策だと思いますが、通常、バージョンの管理と、バージョンの作成とサポートの複雑さに関する深刻な問題につながります。
Fake Framework-として動作する拡張子をstatic library持つバンドルを作成するための、の下での特定の操作の結果です。この手法は、フレームワークテンプレートがなかったため、Xcodeがフレームワークの作成をサポートしていなかった場合に使用されました。偽のフレームワークの実現の1つ。Xcode 6で、AppleはiOSフレームワークのサポートを追加しました。.frameworkdynamic framework
Modular Framework【概要】 -ファイル@importが入ったフレームワーク.modulemapモジュールにはサブモジュールを含めることができます。主な利点は、を使用してビルド時間を節約できることですModular Framework。
Universal Library or Framework（別名Fat）[lipo] [Aggregatetarget]には複数のアーキテクチャが含まれています。たとえば、リリースビルドは、Build Active Architecture Only [ONLY_ACTIVE_ARCH]を介して調整できるアーチをサポートする必要があります。
XCFramework[About]はXcode11によって導入され、bundle複数のアーキテクチャ（arm、x86_64 ...）とプラットフォーム（iOS、MacOS ...）を含むものです。を置き換える必要がありますUniversal Framework
Dependency【概要】ターゲットの一部としてサードパーティのコードを使用することができます。別のプロジェクト、同じワークスペース内のプロジェクト、別のターゲット、ライブラリ、フレームワークなど、多くのソースからのコードを再利用できます。
静的ライブラリを構築して使用する方法：
動的フレームワークを構築して使用する方法[静的に変更]
また、CocoaPodsの.podspecファイル（http://guides.cocoapods.org/making/private-cocoapods.html#1.-create-a-private-spec-repo）を作成し、他のポッドと同じように使用することもできます。それがあなたのプライベートポッドであり、外の世界には見えないという違いだけです（あなたのポッドがCoreDataモデルを作成する必要がある場合はどうなるかわかりませんが、私が理解しているようにそうではありません）。