の内側に私は、サーバーに要求を送信するためにNSURLSessionDataTaskを（HTTP）を使用してフレームワークを作成していたが、私は例のアプリでフレームワークを使用するとき、それはこのような警告を示しています。iOS9：アプリの転送セキュリティはの.plistフレームワーク
をApp Transport Securityは安全でないため、平文HTTP（http：//）リソースの負荷をブロックしました。一時的な例外は、アプリのInfo.plistファイルで設定できます。
Frameworkの.plistにApp Transport Securityを追加しようとしましたが、まだ動作しませんでした。しかし、フレームワーク外の.plistにApp Transport Securityを追加すると動作します。
この問題のいずれかの解決策がありますか？、感謝
は、この問題を回避するために、あなたのInfo.plistで真の鍵としてNSAllowsArbitraryLoadsを追加します。
AppleがATSを無効にするための正当な理由を提供することをAppleに要求することを説明せずに、この解決策を推奨しないでください。 – wottle
@EmilioPelaezが述べたように、アプリケーションはATSがアクティブであるかどうかを制御します。あなたのフレームワークがATSルールに違反する何かをする場合、フレームワークを使用する各アプリケーションは適切な例外を追加する必要があります。
この現象には、十分な理由があります。たとえば、一般的なネットワークヘルパーフレームワークを取ります。ここで、URLは呼び出し元のアプリケーションによってフレームワーク呼び出しに提供されます。このフレームワークは、ATSが必要かどうかを知る方法がありません。逆に、フレームワークにATS例外を必要とするハードコーディングされたURLがある場合、呼び出し側のアプリケーション開発者はそれを認識し、フレームワーク開発者が例外を追加した顔によって隠されるべきではありません。私は、開発者として、私が本質的に安全でないフレームワークを使用していたことを知りたいと思うでしょう。後者のシナリオを扱う場合は、フレームワークが適切に機能するために必要な例外をフレームワークドキュメントに入れるだけです。
また、ATSとベストプラクティスとして、はちょうど完全それを無効にしない、特定のドメインのみのためのATSの要件の特定の部分を無効にすることで、セキュリティのリスクを最小限にするために使用することができ、特定の例外があります。必ずそれをしてください。また、Appleは2016年末に多くのATS例外の正当化を要求する予定であったが、現時点では延期されていることを理解する。例外を追加する場合は、App Storeにアプリを提出する際に、Appleによって何らかの理由で尋ねられます。おそらく "スタックオーバーフローがすべてのATSを無効にするように指示したので"ではありません。
フレームワークはATSを制御できません。だからあなたはあなたのドキュメントに書いておかなければなりません。アプリケーション開発者は自分のアプリにATS例外を追加する必要があります。
しかし、そうしないでください。特にフレームワークを作っているなら。時間をかけてサーバーにHTTPSサポートを追加するか、サーバー開発者に連絡して追加してください。 AppleはAllowArbitraryLoads/exceptionsをすぐにサポートすることをやめます。したがって、フレームワークを含むアプリケーションは、なぜ例外が必要なのかについての正当な理由を提示することなく、レビュープロセスを実行することはできません。 Appleはもともと2017年1月1日からサポートを中止する予定でしたが、未知の期間中延期しました。それでも、彼らはいつかやります。将来を計画する方が良いです。
P.S.サーバーを完全に制御できず、サーバー開発者がMarsにあり、フレームワークが実際にそのサーバーと通信する必要がある場合、アプリケーション開発者は状況を説明することでレビューに合格することができます（「サーバー "はApple Reviewチームの正当な理由です）、それぞれの人が何度も何度も何度もやらなければならないでしょう。したがって、HTTPSへの切り替えは簡単です。
例外は、特定のフレームワークではなく、アプリに付与されます。アプリのInfo.plistに追加するだけです。 – EmilioPelaez