1. ホーム
  2. ios

[解決済み] iOS/OSXフレームワークの作成:他の開発者に配布する前にコード化する必要がありますか?

2023-01-09 17:29:14

質問

iOSとOSXのフレームワークの作り方を勉強しています。iOSを例にとると、以下の手順で今のところうまくいっています。

  1. xcodebuild フレームワークで -sdk iphonesimulator と Build アクションを使用します。
  2. xcodebuild フレームワーク -sdk iphoneos とビルドアクションを使用します。
  3. lipo ツールを使ってユニバーサルバイナリを作成し、以下のようにします。 lipo -info が期待通りに生成されるようにします。

ファットファイルのアーキテクチャ。Foo.framework/Foo は次のとおりです: i386 x86_64 armv7 arm64

という質問があります。

  1. 私のフレームワークを使用している開発者が再署名できることを読みました: "Code Sign on Copy" しかし、その前提条件である、すなわち 他の開発者に配布する前に、私の署名IDでユニバーサルバイナリに署名するために、codesignステップを追加する必要がありますか?

  2. 前が肯定的であれば - 私の "iPhone Distribution: ..." ID を使うべきですか、それとも "iPhone Developer: ..." で十分ですか(そうすれば、いくつかの iOS プロジェクトの一部である私のフレームワークはすべての種類の検証、特に App Store 検証に合格します)。

私の回答の背景には、私が多くのサードパーティのフレームワークで見てきた "CodeSign error: Code signing is required for product type 'Framework' in SDK 'iOS 8.3'" および Carthage#235 または "コード オブジェクトがまったく署名されていない" (一例:私が報告した問題 Realm#1998 .

ですから、私のフレームワークのユーザーがそれらを使用する際に、コードサインの問題に遭遇しないことを確認したいのです。

追伸:この質問は、一人の開発者ではなく、フレームワークベンダーである組織に適用されたとき、さらに面白くなります。

どのように解決するのですか?

信頼できる公式な情報源から得られた回答を探しています。

ジャックスラッシュさんの回答は正しいのですが、一部しか語っていないので、私がこの質問をした時に見たかった方法で、私自身の回答を書きたいと思います。

この回答の実態は 2015年7月です。変更になる可能性が高いです。

まず最初に、フレームワークの正しいコード署名のために必要なアクションは、次のように分けられると主張しましょう。 フレームワークの開発者が取らなければならないステップ フレームワークの消費者が取らなければならないステップ。

TLDRです。

OSXフレームワークの場合。 開発者は OSX フレームワークをコード化せずに自由に配布することができます。

iOSフレームワークの場合。 開発者はiOSフレームワークをコード化せずに自由に配布することができます。しかし、開発者はiOSデバイス用にビルドするとき、Xcodeによってフレームワークをコード化するように強制されます。

レーダーがあるから。 "シミュレータスライスを含む iOS フレームワークは App Store に提出できません"。 iOS フレームワークの消費者は "copy_frameworks" や "strip_frameworks" のような特別なスクリプトを実行することを強制され、そのスクリプトは次のように使用されます。 lipo -remove を使用して iOS フレームワークからシミュレータスライスを取り除き、取り除いたフレームワークを再コード化します。 lipo -remove 操作の副作用として除去されるからです。

長い回答が続きます。


この回答は、信頼できる公式の情報源から引用したものではなく、むしろいくつかの経験的な観察に基づいています。

経験則その1: 消費者は、開発者から受け取ったフレームワークを再コード化するので、気にしない。

Github上の有名なオープンソースプロジェクトのバイナリフレームワークディストリビューション はコードネームではありません。 . コマンド codesign -d -vvvv iOSとOSXのバイナリフレームワークのすべてで、コードオブジェクトがまったく署名されていないことを確認しました。いくつかの例を挙げます。 ReactiveCocoa マントル , 領域 , プロミスキット .

この観察から、これらのフレームワークの作者は、消費者が自分の代わりに署名することを意図していることが明らかです。つまり、消費者は、Xcode が提供する "Embed frameworks" の構築フェーズで "Code Sign on Copy" フラッグを使用するか、同じことを手動で行うカスタムシェルスクリプトを使って消費者の代わりにフレームワークに署名しなければなりません。

私は、反対の例、つまり、コード署名のアイデンティティを持つオープンソースのフレームワークを配布する例を見つけられなかったので、回答の残りの部分では、この広く採用されているアプローチを正しいものとして仮定しています。 フレームワーク開発者は、他の開発者にフレームワークを配布する必要はありません。 .

iOS にのみ適用され、完全に開発者の関心事である経験的観察その 2。

消費者は開発者から受け取ったフレームワークがコード化されているかどうかを気にしませんが、開発者は iOS デバイス用にビルドするとき、ビルドプロセスの一部として iOS フレームワークをコード化する必要があります。 なぜなら、そうしないと Xcode がビルドしないからです。 CodeSign error: code signing is required for product type 'Framework' in SDK 'iOS 8.1' . 引用すると ジャスティン・スパー・サマーズ :

<ブロッククオート

OS X フレームワークはビルド時にコード化する必要はありません... 残念ながら、Xcode は iOS フレームワークがビルド時にコード化されることを要求しています。

iPhone Developer" の ID は、デバイス用に iOS フレームワークをビルドするように Xcode を誘導するのに十分です。 Carthage#339 に対するコメントです。 も同じことを言っています。

経験的観測その3:リポツール

lipo toolの具体的な動作。 フレームワークのバイナリに適用された場合、常に再帰的に codeign identities を削除します。 : lipo -create/-remove codesigned framework ... -> not codesigned framework .

これは、観察その1の例のすべてがまったくコード化されていない理由の答えになるかもしれません。リポが適用された後、彼らのコード化のアイデンティティは吹き飛ばされますが、観察その1によれば、消費者はそれを気にしないので、大丈夫です。

この観察は、AppStoreについての次の観察#4と特に関連しています。

経験的観測 #4: シミュレータスライスを含む iOS フレームワークは App Store に提出できない

で広く議論されています。 Realm#1163 カルタゴ#188 とレーダーが開かれています。 rdar://19209161 .

これは完全に消費者の問題です。消費者がアプリケーションに含める iOS ユニバーサル フレームワークについては、アプリケーションがビルドされるときに、そのフレームワークのバイナリからシミュレーター スライスを削除する特別なスクリプト (カスタム Run Script Phase) を実行して、アプリケーションが AppStore 検証にパスできるようにしなければなりません。

私がRealmで見つけたバイナリフレームワークの良い例です。 strip-frameworks.sh .

これは lipo 以外のアーキテクチャのスライスをすべて削除するために ${VALID_ARCHS} で再符号化し、Consumer のアイデンティティである - これは、3番目の観測が働くところです。フレームワークは、リポの操作のために再符号化されます。

Carthage は CopyFrameworks.swift スクリプトがあり、Consumer が含むすべてのフレームワークに対して同じことを行います。シミュレータスライスを取り除き、Consumer に代わってフレームワークを再コード化します。

また、良い記事もあります。 Xcode のダイナミック ライブラリから不要なアーキテクチャを削除する .


それでは、開発者と消費者の両方の視点から、iOS と OSX の両方を作成するために必要な手順の概要を説明します。まずは簡単なほうから。

OSX

開発者です。

  1. OSXフレームワークのビルド
  2. コンシューマに提供する

デベロッパーによるコードサイン作業は必要ありません。

消費者です。

  1. 開発元からOSXフレームワークを受け取る
  2. フレームワークを Frameworks/ ディレクトリにコピーし、quot;Code Sign on Copy" プロセスの一部として、コンシューマに代わって自動的にコード署名を行ないます。

iOS

開発者です。

  1. デバイス用の iOS フレームワークを構築します。Xcodeでコードサインが必要ですが、iPhone Developer"のIDで十分です。
  2. シミュレータ用にiOSフレームワークをビルドします。
  3. 前の 2 つから普遍的な iOS フレームワークを生成する lipo を使用します。この時点で、1 つのステップのコード署名のアイデンティティが失われます: ユニバーサル フレームワーク バイナリ "はまったく署名されていません" しかし、それは "Consumer は気にしない" ので問題ではありません。
  4. 消費者に渡す

消費者に

  1. デベロッパーからiOSフレームワークを受け取る
  2. フレームワークをFrameworks/ディレクトリにコピーする (ステップ3のスクリプトの内容によっては、このステップは冗長になる可能性があります。)
  3. ビルド プロセスの一部として特別なスクリプトを使用します。このスクリプトは、iOS フレームワークからシミュレーター スライスを取り除き、次に彼ら (Consumer) の代わりにそれを再コード化します。