App Storeレビューをどう増やすか — SKStoreReviewControllerの依頼タイミング設計

以前の記事では、App Store審査を通すためのメタデータ準備を扱いました。今回はそれとは別の話で、審査を通ってリリースした後の話です。GeoConverterPro・GeoPrism JPには現時点でレビュー依頼機能は実装していませんが、実装するとしたらどう設計すべきかを検討したので、その考え方を整理します。

※本記事はGeoConverterPro・GeoPrism JPでの実装事例ではなく、SKStoreReviewController の仕様を踏まえた設計方針の検討メモです。

SKStoreReviewControllerでできること・できないこと

iOSアプリでレビューを依頼する標準の仕組みは SKStoreReviewController（iOS 18以降は RequestReviewAction）です。仕組み自体はシンプルで、コード側から「レビューダイアログを出したい」とリクエストするだけです。ただし、実際に何が起こるかはApple側が完全にコントロールしています。

Appleは「同一ユーザーに対して一定期間内に表示できる回数」を内部的に制限しており、その具体的な回数・期間は公開されていません。つまり、開発側が「レビューを書いてほしい」と思うタイミングでリクエストを送っても、ダイアログが実際に出るとは限らない、という前提で設計する必要があります。

呼び出すタイミングの設計

ダイアログが実際に出るかどうかをAppleがコントロールしている以上、開発側でコントロールできるのは「いつリクエストを送るか」だけです。ここの設計がレビュー獲得数を左右します。

• 「良い体験の直後」を狙う：GeoConverterProなら座標変換に成功して結果を保存できた瞬間、GeoPrism JPならヒートマップやクイズで「なるほど」と思える結果が出た瞬間など、ユーザーが満足している可能性が高いタイミングを狙うのが定石です。
• アプリ起動直後には呼ばない：起動してすぐレビューを求めても、まだアプリの価値を体感していないため印象が悪くなりがちです。
• エラー発生直後には呼ばない：変換に失敗した直後、位置情報の取得に失敗した直後などにレビューを求めると、低評価につながりやすいタイミングです。
• 一定の利用回数・期間を経てから：初回起動ではなく、「変換をN回成功させた」「アプリをM日以上使っている」といった条件を自前でカウントし、閾値を超えたユーザーにだけリクエストを送ります。

自前のスロットリングを入れる理由

Apple側の表示回数制限は非公開かつアプリ側から検知できないため、「呼べば呼ぶほど得」という考え方は成立しません。むしろ自前でも呼び出し頻度を抑える設計にしておいたほうが安全です。

• 同一バージョン内での再リクエストを避ける：一度リクエストを送ったユーザーには、アプリの大きなアップデートがあるまで再度呼ばないようにする、といった自前のフラグ管理を入れておきます。
• UserDefaultsで最終リクエスト日を記録する：「前回リクエストから30日以上経過」のような条件を自前で持たせておくと、Apple側の制限とは独立に「呼びすぎ」を防げます。
• アプリ内の他の通知・ダイアログと競合させない：他のポップアップ（機能紹介、アップデート案内など）と同時に出さないよう、アプリ内で「今どのダイアログを出す権利があるか」を一元管理しておくと事故が減ります。

コード上の位置づけ（実装する場合の見立て）

SKStoreReviewController.requestReview(in:)（あるいは RequestReviewAction）の呼び出し自体は1行で済みますが、実務でコストがかかるのは「呼び出す条件をどこで判定するか」の設計です。GeoConverterPro・GeoPrism JPに実装するとすれば、変換・可視化などの主要機能が成功した直後のイベントハンドラの中に、上記の自前スロットリング条件と合わせて判定ロジックを置く形が素直だと考えています（本記事執筆時点では未実装で、今後の検討項目です）。UIそのものに手を入れる必要がないぶん、条件判定さえ整理しておけば実装コスト自体は小さい機能のはずです。

まとめ

• SKStoreReviewController はダイアログの表示可否をApple側が制御しており、呼び出しても必ず表示されるとは限らない。
• 開発側がコントロールできるのは「呼び出すタイミング」のみ。良い体験の直後・エラー直後を避ける・一定の利用実績を条件にする、という3点が基本方針になる。
• Apple側の表示回数制限は非公開なので、自前でも呼び出し頻度を抑えるスロットリングを入れておくと安全。
• 実装コストは小さいが、「いつ呼ぶか」の条件設計にこそ検討の価値がある。

出典

• 本記事はGeoConverterPro・GeoPrism JPでの実装事例ではなく、SKStoreReviewController / RequestReviewAction の公開仕様に基づく設計方針の検討メモです。仕様は変更されるため、実装時は必ずApple公式ドキュメントを確認してください。

関連記事（参考情報）

• App Store審査を通すメタデータ準備 — スクリーンショット・説明文・プライバシー申告の実務チェックリスト（GCVP）
• SwiftUIで座標入力フォームを作る — 桁数・符号・貼り付け対策（GCVP）
• アプリ名の衝突を事前チェックする — GeoPrism改名の顛末（GPRM）
• 1人開発にAIレビュアーを置く（GPRM）
• MAUIアプリのiOS検証フロー — 実機・TestFlightまでの手順（GDE）

開発者より: アプリ・Kindle本・オープンソースの一覧は GitHub: amru195704 にまとめています。

お願い
本記事の情報は参考目的で掲載しており、正確性・完全性を保証するものではありません。誤記・不正確な情報がございましたら、コメント欄よりご指摘いただければ、確認のうえ修正いたします。

アプリを入手（App Store）：GeoConverterPro（座標変換）　｜　GeoPrism JP（測地系の可視化・学習）