開発者は、多くの場合、新しいプロジェクトに表示される典型的なタスクに直面しています。補助コードのベースは徐々に蓄積され、ライブラリに収集され、プロジェクトからプロジェクトに転送されます。そして、プロジェクトが増えるほど、そのようなライブラリを維持することが難しくなります。

NSFoundation / UIKitを介して、ネットワークやプッシュ通知で使用できる便利なものや、何かのためにお気に入りのカテゴリのセットを持っている可能性があります。このコードをライブラリに配置し、1か所に保存して、パッケージマネージャー（cocoapodsなど）を使用して接続することは論理的です。 Cocoapodsは、プロジェクトへの依存関係の統合を大幅に促進します。彼はあなたのためにすべてを行い、必要なターゲットを作成し、プロジェクトを統合します。このような簡単さとシンプルさは、ソースコードと統合の例のみで構成されるポッドがよく見つかるという事実につながります。このアプローチは公式に推奨されています。実際、これはココアポッドを介した統合には十分ですが、開発とサポートには十分ではありません。このためには、ライブラリを構築できるXcodeプロジェクトが最適です。

Xcodeプロジェクト

テストライブラリUtilities

名前を付けて、Xcodeプロジェクトを作成します。このアプローチの利点は明らかです。

必要なビルドパラメータ（ -Wall

/ -Weverything

、iOS7 + / iOS8 +など）を構成し、デバッグ中（および統合中ではなく）にエラーを処理できます。
単体テストを追加できます
ココアポッドによる統合に加えて、手動またはgitサブモジュールによるCarthageによる統合の可能性があります。

静的ライブラリとフレームワーク

プロジェクトを作成するとき、収集するものを選択する必要があります：ライブラリ（静的ライブラリ）またはフレームワーク（動的フレームワーク）。主な違いは、フレームワークがiOS7と互換性がなく、ライブラリがswiftでサポートされていないことです。

私たちの場合、iOS7のサポートは必要ないため、フレームワークは適切です。

ファイル構造

プロジェクトを作成したら、ライブラリがパッケージマネージャーと互換性を持つように、プロジェクトのファイル構造を変更する必要があります。最も一般的に使用されるパッケージマネージャーは、もちろん、Cocoapodsです。残りはあまり使用されませんが、更新後に毎回更新されたpodspec

をリポジトリにアップロードする必要がないため、保守が容易です。

ソコアポッド

ココアポッドをサポートするには、次のものが必要です。

podspec

ファイルを追加
LICENSE

ファイルを追加

チームがこれをお手伝いします。

 pod spec create

さらに、ライブラリを公開したくない場合は、プライベートパッケージリポジトリを作成する必要があります。そして、 podspec

ファイルを追加します：

 pod repo add myrepostorage https://github.com/user/podspecs pod repo push myrepostorage Utilities.podspec

podspec

ファイルの例：

 Pod::Spec.new do |s| s.name = "Utilities" s.version = "0.0.1" s.summary = "My test library" s.homepage = "https://github.com/user/utilities" s.authors = "author name" s.license = "MIT" s.platform = :ios, "8.0" s.source = { :git => "https://github.com/user/utilities.git", :tag => "#{s.version}" } s.source_files = "Sources/**/*" end

Swiftパッケージマネージャー

Swift PMをサポートするには、以下を行う必要があります。

Sources

フォルダーにSources

ます
Package.swift

ファイルを追加します

Package.swift

例：

 import PackageDescription let package = Package( name: "Utilities" )

カルタゴ

カルタゴをサポートするには、以下を行う必要があります。

xcodeproj

プロジェクトxcodeproj

はルートフォルダにありました
プロジェクトの回路は共有としてマークされました

さらに、それは傷つきません：

githubのREADME.md

に説明を追加
単体テストをTests

フォルダーに入れます
Supporting Files

フォルダに補助ファイルを配置します

結果は次の構造になります。

Supporting Files

フォルダーには、プロジェクトにコンパイル設定を適用するDefaults.xcconfig

ファイルがあります。すべてを手動で構成しないように、そのようなすべてのライブラリに配置すると便利です。たとえば、次のように、コードを改善するために厳密な調整を行いたいと思っています。

 CLANG_WARN_ENUM_CONVERSION = YES CLANG_WARN_INT_CONVERSION = YES CLANG_WARN_CONSTANT_CONVERSION = YES CLANG_WARN_BOOL_CONVERSION = YES; CLANG_WARN_ASSIGN_ENUM = YES CLANG_WARN_DEPRECATED_OBJC_IMPLEMENTATIONS = YES CLANG_WARN_IMPLICIT_SIGN_CONVERSION = YES CLANG_WARN_OBJC_IMPLICIT_RETAIN_SELF = YES CLANG_ANALYZER_SECURITY_INSECUREAPI_RAND = YES GCC_WARN_CHECK_SWITCH_STATEMENTS = YES GCC_WARN_64_TO_32_BIT_CONVERSION = YES GCC_WARN_ABOUT_MISSING_NEWLINE = YES GCC_WARN_SHADOW = YES GCC_WARN_SIGN_COMPARE = YES GCC_TREAT_WARNINGS_AS_ERRORS = YES WARNING_CFLAGS = -Weverything -Wno-objc-missing-property-synthesis -Wno-gnu -Wno-float-equal -Wno-nullable-to-nonnull-conversion -Wno-auto-import -Wno-direct-ivar-access

依存関係

ライブラリにAFNetworking

などの依存関係がある場合、使い慣れた方法を使用して、通常どおりこの依存関係を統合できます。たとえば、ココアポッドまたはカルタゴを使用して、ライブラリに接続できます。また、バッチマネージャーの対応する構成ファイルでこの依存関係を指定することを忘れないでください。 cocoapodsの場合はPodfile

であり、carhageの場合はCartfile

です。

まとめ

その結果、任意のパッケージマネージャーを使用して簡単に保守および統合できるライブラリを取得できます。

iOS用のライブラリを作成する