ガイドライン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」の対処法について紹介しました。

今回のリジェクトは、すべてがビルドの問題ではないことを学ぶ良い経験になりました。

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

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