他の人のコードに含まれる商用iOSSDKを構築していて、ライセンスを持っているサードパーティのライブラリがある場合、それらのサードパーティのシンボルをエクスポートしないことでライブラリ/フレームワークの構造を簡素化する効果的な方法はありますか？静的ライブラリ？
重複するシンボルをチェックするように開発者に指示できたことに感謝しますが、指示を最小限に抑えたいと思います。つまり、libをプロジェクトにドロップして、プロジェクトから外してもらいたいだけです。また、サードパーティのシンボルは後のプロジェクトで変更される可能性があるため、エクスポートしたくありません。
残念ながら、ここで簡単にできることはあまりありません。静的ライブラリは、結合された.oファイルの集まりです。.oの間に実際に必要な部分を判別するためのリンカーステップはありません。これは、（顧客による）最後のリンクステップまで実行されません。
そうは言っても、あなたが考えることができるいくつかのことがあります：
まず、可能な限り、静的ライブラリ内にサブライブラリを含めないようにします。顧客が同じサブライブラリの他のコピーを持っている可能性がある場合、これは本当に危険です。サブライブラリがライセンスされているため、状況が異なるように思われるため、顧客が複数のコピーを持っている可能性は低いですが、たとえば、静的ライブラリにlibcurlの静的コピーを含めないでください。libcurlを自分でリンクするように顧客に依頼する必要があります。そうしないと、物事が非常にひどく爆発します。（別の静的ライブラリを共有する静的ライブラリのリンクを参照してください。）繰り返しになりますが、これは当てはまらないように思われますが、共通のオープンソースライブラリが混在している場合は注意してください。
可視性に対処するための昔ながらの解決策は、コンパイルユニットを接着することです。これは、「すべての.c/.mファイルを1つの大きなファイルに連結してコンパイルする」という素晴らしい言い方です。「静的」とマークした関数は、このコンパイルユニットの外部には表示されないため、エクスポートしないでください。これにより、ライブラリ内でのコンパイラのインライン化やその他の最適化（特に、リンク時の高度な最適化なし）の可能性も高まります。
シンボルエクスポート戦略を参照してください。いくつかのオプションがあります。
-fvisibilityします（おそらくここでの最善の策）これらは上記のリンクで説明されています。