SKStoreReviewControllerでアプリ内レビュー依頼を実装してみて分かったこと

Core Motionでの活動データ取得を実装した流れで、以前アプリのレビュー・評価を増やすためにやったことでも触れた技術的な仕組みそのものを実装したいと考え、SKStoreReviewControllerによるアプリ内レビュー依頼機能に挑戦しました。

1. 好きなタイミングでレビュー画面を出せると思っていた

最初、任意のタイミングで確実にレビュー依頼のポップアップを表示できるものだと思い込んでいました。

SKStoreReviewController.requestReview(in: windowScene)

実際にはこのAPIを呼び出しても、必ずしもポップアップが表示されるとは限らない仕組みになっていました。OS側が表示回数やタイミングを内部的に制御しており、開発者側からは「表示をリクエストする」ことしかできず、実際に出すかどうかの最終判断はシステムに委ねられていると分かりました。

動作確認のためにボタンを押すたびにレビュー依頼のAPIを呼び出していたところ、最初の数回は表示されたものの、その後まったく表示されなくなってしまいました。

Appleの制約:
同一アプリに対する表示回数は一定期間内で上限がある

これはバグではなく、同じユーザーに対して短期間に何度もレビュー依頼を表示しないようにするAppleの制約によるものでした。開発中の動作確認で「表示されなくなった」場合、実装ミスではなくこの表示回数制限が原因であることが多いと学びました。

とりあえず実装した機能をすぐに試したいという気持ちから、アプリ起動直後にレビュー依頼を呼び出す実装にしてしまっていました。

見直した呼び出しタイミング:
何らかの操作が正常に完了した直後（良い体験の直後）

アプリを開いた直後のような、ユーザーがまだ何も達成していないタイミングでレビューを求めるのは印象が良くありません。何かの操作を完了した直後や、アプリを気に入って使い続けているとみられるタイミング（一定回数の利用後など）に呼び出しを移し、より自然な依頼になるよう調整しました。

表示回数制限があることを理解した後、動作確認のたびに毎回表示を確認したかったのですが、通常の実行では制限にすぐ引っかかってしまい、確認作業がはかどりませんでした。

確認方法:
Xcodeのスキーム設定でStoreKit Configuration Fileを使ったテスト環境を用意

調べてみると、StoreKitのテスト用設定を使うことで、本番の表示制限を気にせず動作確認できる環境を用意できることが分かりました。本番の制約とテスト時の確認しやすさは別問題として、開発環境を分けて考える必要があると気づきました。

「呼べば出る」機能ではなく、Appleの制約とユーザー体験の両方を意識して初めてうまく機能する仕組みだと実感した実装でした。

本記事は生成AI（Claude）を活用して執筆・編集しています。内容は実体験に基づき、執筆者本人が確認・監修しています。