スクリプトを使用せずにシミュレータスライスを取り除く動的フレームワークの作成方法

Question

動的フレームワークを作成して配布したいと思います。それはシミュレータ、iPhoneデバイス上で動作し、App Storeに提出できるようにする必要があります。

lipo私はこのguideのおかげで分かっています。シミュレータアーキテクチャとiphoneアーキテクチャをどのように組み合わせて、ソースコードを配布せずに配布できる単一の動的フレームワークにするかを示しています。それは私が両方のシミュレータとiPhoneデバイスのフレームワークを使用することができます。しかし、それをApp Store because of the simulator buildに送信しようとすると失敗します。

カルタージュは、興味深い解決策を提供します。これは、シミュレータとiPhoneの両方で動作するフレームワークを作成します。しかし、App Storeに送るときは、シミュレータスライスを取り出すためのスクリプトを実行する必要があります。

しかし、出版（DFP）用のDoubleClickの作成者は、シミュレータとデバイスの両方で動作するフレームワークを作成する方法を発見しました。 App Storeの投稿を渡します。また、シミュレータスライス（AFAIK）を取り出すためのスクリプトは必要ありません。私が実際にやらなければならないのは、GoogleMobileAds.frameworkファイルをLinked Frameworks and Librariesにドラッグすることだけです。 Embedded Binariesのように、ほとんどの動的フレームワークに追加する必要はありません。少し驚くべきことです）

これを実証するDFPを使用するサンプルプロジェクトを作成しました。

// clone repository 
git clone --recursive https://github.com/wh1pch81n/DoubleClickGoogleExample.git 

// Move to correct branch 
git submodule foreach 'git checkout master' 
git submodule foreach 'git pull origin master' 

ここで、Simulation_mate方式を選択してアプリを実行できます。アプリは、広告が実際に動作していることを示すために、下部に単一の広告バナーを表示します。

依存グラフは次のようになります。

Simulation_mate.app 
    -> Mate.framework 
     -> DFP.framework 
     -> GoogleMobileAds.framework 

また、シミュレータ、iPhoneでSimulation_mateを実行してApp Storeに送信できます。

私の質問は、世界でどのようにGoogleMobileAds.frameworkをこのように作成したかです。このようなフレームワークを作成するためには、どのような手順に従う必要がありますか？

Answer 1

GoogleMobileAds.frameworkは、動的フレームワークではなく静的フレームワークであると考えられます。動的なフレームワーク上でfileを実行しているのに対し

> file GoogleMobileAds 
GoogleMobileAds: Mach-O universal binary with 5 architectures: [arm_v7: current ar archive] [arm_v7s] [i386] [x86_64] [arm64] 
GoogleMobileAds (for architecture armv7): current ar archive 
GoogleMobileAds (for architecture armv7s): current ar archive 
GoogleMobileAds (for architecture i386): current ar archive random library 
GoogleMobileAds (for architecture x86_64): current ar archive random library 
GoogleMobileAds (for architecture arm64): current ar archive 

、あなたは異なる結果が得られます。

> file AppKit 
AppKit: Mach-O universal binary with 2 architectures: [i386: Mach-O dynamically linked shared library i386] [x86_64] 
AppKit (for architecture i386): Mach-O dynamically linked shared library i386 
AppKit (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64 

は残念ながら、あなたが記述問題は、App Storeの配信システムの既知の制限です。理論的には、動的フレームワークを配布する正しい方法は、すべてのアーキテクチャでフル・ファット・バイナリを配布し、ビルド・システムがビルド時に不要なアーキテクチャを破棄するか、またはApp Store配布システムで特定のデバイス用のアプリ（ "slicing"）。私が推測しなければならないのは、App Storeからのスライシングをサポートしていないため、iOS 8以降のサポートのため、このようなフレームワークでApp Storeの配布が失敗するということです。

Googleが静的ライブラリを作成する理由は、iOS 7をサポートするためです。この頃の愚かな理由から、開発者にとっては、GoogleがCocoaPodの使用を主張しているため、多くの問題が生じています。静的なフレームワークは、表面的には最初は銀色の弾丸のように見えますが（実際にはlipoアウトアーチ、埋め込みなし）、実際にはそれほど大きくありません。たとえば、コンパイルされていないリソースを含める場合、静的フレームワークはそのトリックを行いません（動的フレームワークはバンドルですが、静的フレームワークはバンドルされません）。