拒否にさよなら、iOS レビューの合格率を向上させる方法 (パート 1)

iOS のレビューは、Apple Store に公開されるすべてのモバイル製品にとって常に大きな課題でした。すべてのレビューは長くて悲惨な旅のようなもので、Apple はそれを拒否することが多く、非常に苦痛です。そこで質問なのですが、 Apple のレビュー基準を正確に把握し、レビュー合格率を向上させる方法はあるのでしょうか?答えはイエスです。テンセントの事前審査チームは、次の 2 つの側面を調査しました。ほぼ 1 年間の実装とデータ監視を経て、毎月の iOS レビュー合格率は 35% から 85% 以上に増加しました。

1. 過去に拒否されたアプリケーションの事例を分析し、 Apple App Store レビューガイドラインの条件に従って実行可能なレビュー項目に整理します。

2. 監査の効率を向上させるために自動化できる方法を抽出する。

次に、Apple のレビューに進み、iOS レビューの真実を明らかにします。この記事は、iOS 監査を 3 つのレベルで紹介するものです。

1. iOS監査の秘密: 監査機器
2. iOSレビュー拒否理由の分析
3. テンセント事前審査チームによるiOS事前審査承認の次元

1. iOS監査の秘密: 監査機器

Apple製品は2007年に発売されて以来、徐々にアップデートされ、すでに多くの製品ハードウェアバージョンやシステムバージョンが外部市場に出回っています。システム バージョンが多数ある場合、レビューのために提出されたバージョンの品質をどのように保証すればよいのでしょうか。これは、テスト チームと製品チームにとって常に悩みの種でした。

Apple は突然新しいシステムをリリースすることがよくあります。こうしたリスクにはどのように対処すればよいのでしょうか?

【クラシックケース】

2014 年末、新しい iOS バージョン 8.1.1 のリリースにより、いくつかの根本的なシステム バグが修正されましたが、その結果、ゲーム製品の支払いが失敗し、Webview ログインが失敗しました。

【主な施策】

1. Appleと同じ承認バージョンに従います。

Apple のレビュー チームも、機器の選択と受け入れの際に、最近リリースされた 2 つのシステム バージョンと 2 つのハードウェア バージョンを受け入れるという原則に従うと推測されます。市場シェアが最も高い 2 つのシステム バージョンとハードウェア構成でゲームがスムーズに実行できることを確認します。

そのため、テンセントの事前検査チームは、現在のバージョンのリリースリズムに応じて機器を購入し、システムをアップグレードして、上記のシステムバージョンとハードウェアバージョンがカバーされるようにします。現在受け入れられている機械とモデルのリスト:

2. ベータ版に注意してください:

Apple は、新しいバージョンがオンラインになる前に、少量のテスト用にベータ版をリリースします。このとき、ベータ版をフォローして事前に問題を発見し、突然のバージョンリリースに驚かされないようにする必要があります。

2. iOSレビュー拒否理由の分析

拒否のより深いレベルを探るために、詳細な分析を実施し、過去数年のレビューデータ統計を使用して拒否の理由を確認しました。

3. 監査前の事業承認の側面

2014 年の統計と Apple App Storeレビューガイドラインに基づいて、事前レビューチームは事前レビュー作業をクライアント リソース検査、アプリケーション コンテンツ検査、レビュー リソース検査の 3 つのモジュールに分割しました。

クライアントリソースチェック

クライアントの Plist およびその他の構成が Apple の要件を満たしており、冗長なキー値が有効になっていないことを確認します。

アプリケーションコンテンツの検査

アプリのコンテンツを見直して、ポルノ、下品、暴力、銃器関連のコンテンツが含まれていないことを確認します。告知文を精査して、Apple が禁止している言葉が含まれていないことを確認します。アプリには、CD キーの引き換え、友達の招待、自慢など、Apple が最近禁止したコンテンツが含まれていません。

リソース検査を確認する

提出するゲームのスクリーンショットやビデオが Apple の要件を満たし、機密情報が含まれていないことを確認してください。同時に、ビデオのスクリーンショットなどは Apple の技術要件を満たし、フレーム レートと解像度が標準を満たしていることを確認してください。

本記事では、まずAppleのレビューの関連内容を簡単に紹介します。その後、ビジネス受け入れの観点から、受け入れのポイント、遭遇した落とし穴、不安にさせる拒否事例などを一つずつ紹介します。

まずはクライアントの検査から始めましょう。

クライアント チェックの主な目的は、ストレージ システム、構成ファイル、ネットワーク接続、アイコン チェック、プライベート API チェックなどのクライアント構成チェックを通じて、クライアントが Apple の開発者仕様およびその他の更新された要件に準拠していることを確認することです。事前レビューでは、これらの部分の各テスト ポイントがカバーされます。

1. ストレージシステムのチェック

Apple はユーザーデータの保存に関して厳しい規制を設けており、過去の拒否事例の多くは保存に関連したものでした。したがって、Apple の公式データ保存ガイドラインの関連内容を理解する必要があります。

【クラシックケース】

[事例1] プロジェクトAのバージョンxx0は、アプリの起動後にユーザーのiCloudに22.17MBのデータが保存され（通常は1MBを超えてはならない）、iOSのデータ保存ガイドラインに準拠していなかったため却下されました。

解決策: 増分更新の累積ファイルが大きすぎたため、修復後にレビューに合格しました。

[ケース 2] プロジェクト B のバージョン xx5 は、iOS のデータ保存ガイドラインに従っていないため拒否されました。リソース ファイルはアプリケーションのドキュメント ディレクトリに保存されていました。このディレクトリは iCloud に同期されるため、Apple ではユーザーが生成したファイル以外のファイルをこのディレクトリに配置することを許可していません。

解決策: ライブラリ/キャッシュに存在する必要があるローカル リソース ファイルを変更します。

2. 設定ファイル（Info.plist）の確認

Info.plist は構造化テキスト ファイルで、一般に「プロパティ リスト」と呼ばれます。iOS アプリは Info.plist ファイルを使用してメタ情報を保存し、バンドルによって表示されるアイコン、現在のアプリでサポートされているドキュメントの種類、サービス宣言などを決定するために使用されます。検査のこの部分に関しては、通常、次の点に重点を置きます。

【クラシックケース】

プロジェクト C のバージョン x.x1 は、Info.plist 設定の問題により拒否されました。つまり、アプリケーションにはファイル共有機能は必要ありませんでしたが、Info.plist の UIFileSharingEnabled キーが true に設定されていました。

回避策: Info.plist の UIFileSharingEnabled キーを false に設定します。

3. ネットワーク接続

ほとんどのアプリレビューサーバーは中国に配備されていますが、Apple の iOS レビューチームは米国にあります。レビューを実施するときは、米国のネットワークを使用します。このような大陸間のネットワーク接続では、必然的に高遅延、ジッター、パケット損失などのネットワーク問題が発生します。

【クラシックケース】

「プロジェクト D」は米国の IP からアクセスできなかったため拒否されました。

4. アイコンチェック

Apple は、iPhone、iPad、iPod などのアプリケーションのアイコンに対して明確な要件を設けています。パッケージには、180×180、120×120、76×76、152×152 のサイズの PNG 形式のアイコンが含まれている必要があり (詳細については下の表を参照)、異なるサイズのアイコンの内容は一貫している必要があります。

アプリアイコンのチェックに関しては、テンセントの事前検査チームは自動化された方法を使用して、ipa パッケージを自動的に解凍し、アイコンが存在し、要件を満たしているかどうかを 1 つずつ検証します。要件を満たしていない ipa パッケージについては、警告プロンプトが表示されます。

【クラシックケース】

「プロジェクト E」の xxx バージョンは事前審査済みですが、関連するアイコン画像リソースが提供されていません。このバージョンが正式に審査に提出され、Apple の審査結果が保留中の場合、拒否されるだけです。

5. プライベートAPIチェック

プライベート API とは、プライベート フレームワーク フレームワークに配置された API を指します。プライベート API を呼び出しているために、アプリがレビュー中に拒否されることは珍しくありません。最近、Apple はプライベート API を呼び出しているため、「 Where Are We Going, Dad 2」や「Find Your Sister」を含む 256 個のアプリを削除しました。Apple がアプリによるこのような API の使用を明示的に許可していないことは明らかです。

非公開 API は Frameworks フレームワークに配置されていますが、Apple の公式ドキュメントには使用方法やコードの紹介などが記載されていません。 Apple によると、未公開 API は、十分に成熟しておらず、変更される可能性がある API です。完全に完成すれば公開 API になりますが、現時点では確約されておらず、システム バージョンがアップグレードされると無効になる可能性があります。非公開 API に関しては、Apple の iOS レビューガイドラインの第 2.5 条にも、アプリが非公開 API を使用する場合は拒否されることが明記されています (2.5 非公開 API を使用するアプリは拒否されます)。

プライベート API の検査に関しては、自動化ツールスキャンを使用して実装します。実装の原則は次のとおりです。

① 未公開ライブラリを取得する：iOS SDKに基づいて、ライブラリ全体をダンプし、ライブラリ全体からプライベートライブラリとパブリックライブラリを減算して、未公開ライブラリ（非公開API）を取得します。

② ヘッダーファイルのメソッドとメンバーのリストを取得します。Otool などのツールを使用して、ipa 実行可能ファイルを逆コンパイルおよび解析し、ヘッダーファイル内のメソッドとメンバーのリストを取得します。

③ 非公開ライブラリおよびプライベートライブラリとの一致: リスト内のメソッドとメンバーをそれぞれプライベートライブラリおよび非公開ライブラリと一致させます。一致しない場合はスキャンは成功します。一致した場合はスキャンは失敗します (警告と API 名が提供されます)。

IV. 結論

1. 実際には、ストレージ システムの検査は、ユーザーのローカル ストレージ領域と Apple iCloud サーバー ストレージを合理的に使用してスペースを節約するなど、一連の概念に従った一連の仕様です。

2. Info.plist ファイルのチェックは、実際には XML ファイルのキー値チェックであり、値チェックの関係は並列です。ストレージ ファイルと plist の使用例をチェックすることで、このタイプの理由による拒否は基本的に回避されます。

3. プライベート API 検査は、自動化されたツールスキャンによって実現されます。

モバイルアプリケーション製品プロモーションサービス： APPプロモーションサービス青瓜メディア広告

この記事の著者は@郑卓然で、(Qinggua Media)が編集・出版したものです。転載の際は著者情報と出典を明記してください。