私は賞金を開きました：「信頼できるおよび/または公式の情報源から引き出された答えを探しています。」しかし、それ以来、そのようなものを受け取っていません。
@jackslashの回答は正解ですが、話の一部しか伝えていないので、この質問をした瞬間に見たかったような書き方をしたいと思います。
この回答の実際は2015年7月です。状況が変わる可能性が最も高いです。
フレームワークの正しいコード署名のために必要な措置を分けする必要があることをすべてのletのアサートの最初のフレームワークの開発を取るために持っていることのステップとフレームワークの消費者が取るために持っていることの手順。
TLDR;
OSXフレームワークの場合：コンシューマーがとにかく再設計するため、開発者はコード署名せずにOSXフレームワークを自由に配布できます。
iOSフレームワークの場合：コンシューマーがとにかく再共同設計するため、開発者はコード署名せずにiOSフレームワークを自由に配布できますが、開発者はiOSデバイス用にビルドするときにXcodeによってフレームワークをコード署名する必要があります。
レーダーのため：「シミュレータースライスを含むiOSフレームワークはApp Storeに送信できません」iOSフレームワークの消費者は、iOSフレームワークlipo -removeからシミュレータースライスを取り除き、再実行するために使用する「copy_frameworks」や「strip_frameworks」などの特別なスクリプトを実行する必要があります。-codesignsはフレームワークを削除しました。これは、この時点で、コード署名IDがlipo -remove操作の副作用として削除されたためです。
より長い答えが続きます。
この答えは「信頼できるおよび/または公式の情報源からの引用」ではなく、多くの経験的観察に基づいています。
経験的観察＃1：消費者は、開発者から受け取ったフレームワークを再設計するため、気にしません
Github上の有名なオープンソースプロジェクトのバイナリフレームワークディストリビューションはコード署名されていません。コマンドcodesign -d -vvvvは、私が調査したすべてのバイナリiOSおよびOSXフレームワークで「コードオブジェクトはまったく署名されていません」と表示します。いくつかの例： ReactiveCocoaと Mantle、Realm、PromiseKit。
この観察から、これらのフレームワークの作成者は、コンシューマーがコード署名することを意図していることは明らかです。つまり、コンシューマーは、Xcodeが提供する「埋め込みフレームワーク」ビルドフェーズで「コードサインオンコピー」フラグを使用するか、カスタムシェルを使用する必要があります。同じことを手動で行うスクリプト：コンシューマーに代わってcodesignsフレームワーク。
反対の例は1つも見つかりませんでした。コード署名IDを使用して配布されるオープンソースフレームワークであるため、残りの回答では、この広く採用されているアプローチを正しいものと想定しています。フレームワーク開発者が行う必要はありません。コンシューマーはとにかくそれを再設計するので、フレームワークをコード署名IDを持つ他の開発者に配布します。
iOSのみに適用され、完全に開発者の関心事である経験的観察＃2
コンシューマーは、開発者から受け取ったフレームワークがコード署名されているかどうかを気にしませんが、開発者は、iOSデバイス用にビルドするときに、ビルドプロセスの一部としてiOSフレームワークをコード署名する必要がありますCodeSign error: code signing is required for product type 'Framework' in SDK 'iOS 8.1'。そうしないと、Xcodeはビルドされません。Justin Spahr-Summersを引用するには：
OS Xフレームワークはビルド時にコード署名する必要はありません...残念ながら、XcodeではiOSフレームワークをビルド時にコード署名する必要があります。
これは私の質問＃2にかなりよく答えます：「iPhone開発者」のアイデンティティは、デバイス用のiOSフレームワークを構築するためにXcodeをキャジョルするのに十分です。Carthage＃339に関するこのコメントは同じことを言っています。
経験的観察＃3：リポツール
リポツールの特定の動作：フレームワークバイナリに適用すると、コードサインIDが常に再帰的に削除されます：lipo -create/-remove codesigned framework ... -> not codesigned framework。
これは、観察＃1のすべての例がコード署名されていない理由の答えである可能性があります。lipoが適用された後、それらのコード署名IDは吹き飛ばされますが、観察＃1によると、消費者はそれで問題ありません。
この観察結果は、AppStoreに関する次の観察結果＃4に特に関連しています。
経験的観察＃4：シミュレータースライスを含むiOSフレームワークをAppStoreに送信できません
これは、Realm＃1163とCarthage＃188で広く議論されており、レーダーが開かれています：rdar：// 19209161。
これは完全にコンシューマーの懸念事項です。コンシューマーがアプリケーションに含めるiOSユニバーサルフレームワークの場合、アプリケーションのビルド時に、アプリがAppStore検証に合格できるように、フレームワークのバイナリからシミュレータースライスを削除する特別なスクリプト（カスタム実行スクリプトフェーズ）を実行する必要があります。
Realmで見つけたバイナリフレームワークの良い例：strip-frameworks.sh。
これはlipo、アーキテクチャのすべてのスライスを削除してから${VALID_ARCHS}、コンシューマーのIDで再設計するために使用します。ここで、観察＃3が始まります。フレームワークは、リポ操作のために再設計されます。
CarthageにはCopyFrameworks.swiftスクリプトがあり、Consumerに含まれるすべてのフレームワークに対して同じことを行います。Consumerに代わってシミュレータースライスを取り除き、フレームワークを再設計します。
また、良い記事があります：Xcodeのダイナミックライブラリから不要なアーキテクチャを取り除く。
ここで、開発者と消費者の両方の観点からiOSとOSXの両方を作成するために必要な手順の概要を説明します。まず簡単なもの：
OSX
開発者：
- OSXフレームワークを構築します
- 消費者にそれを与える
開発者によるコード署名アクティビティは必要ありません。
消費者：
- 開発者からOSXフレームワークを受け取ります
- フレームワークをFrameworks /ディレクトリにコピーし、「Code Sign on Copy」プロセスの一部として、コンシューマーに代わって自動的にコード署名します。
iOS
開発者：
- デバイス用のiOSフレームワークを構築します。Xcodeでは共同設計が必要です。「iPhone開発者」のアイデンティティで十分です。
- シミュレーター用のiOSフレームワークを構築します。
- 前の2つからユニバーサルiOSフレームワークを生成するlipoを使用します。この時点で、1ステップのコード署名IDが失われます。ユニバーサルフレームワークバイナリは「まったく署名されていません」が、「消費者は気にしない」ので問題ありません。
- 消費者にそれを与える
消費者：
- 開発者からiOSフレームワークを受け取ります
- フレームワークをFrameworks /ディレクトリにコピーします（このステップは、ステップ3のスクリプトによっては冗長になる場合があります）。
- ビルドプロセスの一部として特別なスクリプトを使用します。このスクリプトは、iOSフレームワークからシミュレータースライスを取り除き、コンシューマーに代わって再コデザインします。