App Storeの提出物がプライベートAPIの使用についてテストされていることが一般に知られているので、質問する必要があります...それらを回避するためのプライベートAPIとは正確には何ですか?
7 に答える
プライベートAPIは、SDKに記載されていないAPIです。たとえば、フレームワーククラスは、外部の開発者が使用することを意図していないメソッドを宣言する場合があります。プライベートAPIの動作は保証されていません。プラットフォームの将来のアップデートでメソッドが存在するかどうかさえ確信できません。その宣言は、公的に配布されているSDKヘッダーファイルではおそらく利用できません。SDKのドキュメントで公に定義されていることに固執すれば、問題はありません。
誤ってプライベートAPIを使用することは困難です。それらはSDKドキュメント内に文書化されておらず、XCodeのコード補完の提案には表示されません。
これが最近ニュースになった理由は、いくつかのアプリで使用されるフレームワークの作成者がプライベートAPIを使用していたため、彼のフレームワークを含む開発者がアプリを更新すると、それらは拒否されました(これらの開発者はプライベートAPIを使用していませんでしたが、彼らが彼らのアプリケーションに追加したフレームワークはそうしました)。
これが、プライベートAPIを誤って使用する可能性がある唯一の方法です。
アプリケーションが拒否される原因となるのは、プライベートAPIだけではありません。ドキュメント化されていないパブリックAPIのメンバーを使用すると、アプリケーションが拒否される可能性があります。たとえば、three20ライブラリ(修正されたため)は、カテゴリ内の_phaseおよびUITouchの他のメンバーにアクセスしました。
また、performSelectorを介してプライベートメンバーへの呼び出しを検出することもできます。これは、次の場合も拒否のフラグが立てられているためです。
UIWindow* window = [UIApplication sharedApplication].keyWindow]
return !![window performSelector:@selector(firstResponder)];
さらに厄介なことに、アプリケーションを3.1および3.0で動作させ、実行時に3.0で動作させる場合、アプリケーションが拒否される可能性のある3.1のものを使用しません。例としてはのがありますcameraOverlayView
(UIImagePickerController
ここを参照)。これはちょっと不可解です。
アプリを送信する前に使用できる優れたツールは、AppScannerです。.appファイルをスキャンしてプライベートAPIの使用状況を確認し、どのメソッドシグネチャが一致し、それらのメソッドがどのクラスにあるかを示します。
通常、SDKヘッダーがないためです。Appleの慣習の1つは、ObjCメソッド名をアンダースコアでリードすることです。
プライベートAPIを使用しているため、私のアプリはAppleによって拒否されました。コードは次のとおりです。
Class UIKeyboardImpl = NSClassFromString(@"UIKeyboardImpl");
id activeInstance = [UIKeyboardImpl performSelector:@selector(activeInstance)];
[activeInstance performSelector:@selector(dismissKeyboard)];
いわゆる「プライベートAPIの使用」によって拒否されることは難しくありません。以下をコアデータ属性として使用しようとすると、拒否されます。
- colorIndex
- 発生
- id
ロボットがAPIをスキャンする方法を示しています。