静的（iPhone）ライブラリ、配布、および依存関係

Question

（おそらく次の質問は、私たちがそうでなければフレームワークまたは動的ライブラリを使用する可能性が高いという事実は別に、iPhone特有の問題ではありません。）

私は独自のiPhoneを構築していますクライアント用のSDK、Webバックエンドとの統合ソースコードを顧客に配布したくないので、SDKを静的ライブラリとして配布する必要があります。これはうまくいきます。新しいiPhoneアプリをライブラリにリンクして、デバイスにインストールできることを確認しました。

私の懸念事項は、私たちのSDKが依存する第三者のライブラリです。たとえば、現在HTTPRiotとThree20を使用しています（正確なライブラリは変更されるかもしれませんが、それは重要ではありません）。顧客がこれらのライブラリ（およびおそらく異なるバージョン）のいずれかを自分のアプリでも使用している場合、これによって競合が発生する可能性があると私は心配しています。

これに関するベストプラクティスは何ですか？独自の静的ライブラリから依存ライブラリのシンボルを除外する方法はありますか？その場合、顧客はSDKとHTTPRiotおよびThree20の両方に手動でリンクする必要がありますか？または、他に確立されたメカニズムがいくつかありますか？

私は使いやすさと柔軟性/互換性のバランスを取ろうとしています。理想的には、独自のSDKをプロジェクトにドロップし、ビルド設定の変更を最小限に抑えるだけで済みますが、状況がより堅牢なものになると、顧客が複数のライブラリを個別にリンクするようになる可能性があります。あるいは、第三者依存の有無にかかわらず、複数のバージョンのSDKを配布して、両方のケースをカバーできるとします。

私は私の質問は意味をなさない... RubyとJavaの背景から主に来て、私は長い間（伝統的な意味で）コンパイルされたライブラリに対処しなければならなかったではないと思っている...

;）

Answer 1

私の場合は、私のライブラリと相互運用可能なサードパーティのライブラリのバージョンを正確に指定します。私はそれらに対してテストし、文書化し、おそらくリリースに含まれる特定のバージョンを提供するでしょう。

私が心配している2つのこと：
- お客様がインストールしたときに「うまくいく」ことを確認したいと思います。
- これらのサードパーティライブラリの任意の将来のバージョンのサポートを保証したくないです。

お客様が新しいバージョンに移行するプロセスを含めると問題はありませんが、何かがうまくいかない場合は、無料のバグではなく、その開発作業の費用を顧客に支払うことを期待します修正してください（元のライセンス/サポート契約にそれを含めない限り）。

この時点で、サードパーティのライブラリの特定のバージョンが、お客様のニーズに合ったもの（お客様のウェブバックエンド）と一緒に喜んで働くことが保証されるようになります。私の経験では、通常は図書館の機能です。いくつかは設計されていないので、複数のバージョンを並行して実行することができます。