Performance - App Completenessで何度も更新が却下される場合の対処法を紹介

ガイドライン2.1「Performance - App Completeness」とは？

まずは、ガイドライン2.1「Performance - App Completeness」について紹介します。

Appleのホームページからそのまま引用します。

App Reviewに提出するアプリ（予約注文に対応するアプリも含む）は、必要となるあらゆるメタデータや有効なURLを含む最終バージョンである必要があります。プレースホルダテキスト、コンテンツのないWebサイト、その他の一時的なコンテンツは、すべて提出前に取り除く必要があります。

簡単に説明すると、App Storeに公開するメタデータ（スクリーンショットやアプリの説明文など）に問題があるか、アプリ自体のパフォーマンスに問題があるということです。筆者がリジェクトされた理由は後者でした。

引っかかった理由

筆者はアプリの更新を公開する前に、必ずTestFlightを利用してパフォーマンスのテストを行っていますが、どうやらAppleの審査員がiPadでアプリを開いた際に、一部のページが適切に表示されなかったようです。

リジェクトの際に送られてきたメッセージには、スクリーンショットも添付されていました。

TestFlightでは正しく動作していたにもかかわらず、なぜリジェクトされたのかと疑問に思いながらも、少しコードの変更を行い、再ビルドしてTestFlightで動作確認した後、再提出しましたが、また同じ理由でリジェクトされました。

仕方なく、今回のアップデート内容をメタデータの変更のみにし、アプリは前回審査に通ったバージョンと同じものをビルドして提出しましたが、それでも再びリジェクトされてしまいました。

前回通ったビルドでは確実に適切に表示されていたはずなのに、同じ理由でリジェクトされたため、謎でした。

対処法

「Appleのレビュワーが利用するiPadの通信環境が悪かったのでは？」と一瞬思いましたが、普通に考えてそんなわけないですよね。

とはいえ、筆者のTestFlight環境では正しく動作していたので、そう思ってしまうのも無理はありません。

これには、別の理由がありました。

それは、「提出の取り消し」を行わずに再提出をしていたことです。どうやら「提出の取り消し」を行わないと、再提出しても前のビルドが審査されてしまうようです。

つまり、筆者は何度もビルドを更新して提出していたつもりでしたが、実際に審査されていたのはずっと最初のビルドだったということになります。

その後、「提出の取り消し」を行い、改めて新しいビルドを提出したところ、すぐに審査に通過しました。最初のバグの原因が何だったのかは謎のままですが、無事に審査が通ったので、今回は良しとしました。

※「提出の取り消し」は「App Store Connect」の「App Review」のレビュワーからのメッセージの下にあります。

最後に

ここまで、ガイドライン2.1「Performance - App Completeness」の対処法について紹介しました。

ビルドを変更して再提出する際には、必ず「提出の取り消し」を行うようにしましょう。

ここまでお読みいただき、ありがとうございました。