Tutorial7 min read

Ask for App Store and Google Play ratings in a Capacitor app

How to show the native rating prompt in a Capacitor app on iOS and Android, the limits Apple and Google enforce, the moments that earn good reviews, and how to test it.

Ratings decide more than people think. They affect where your app ranks in search, whether a visitor installs it, and how much your paid acquisition costs. Most happy users never rate an app on their own. Unhappy ones do. The native in-app review prompt is the simplest way to fix that imbalance, and in a Capacitor app it takes one plugin and one function call.

The hard part is not the code. It is asking at the right moment, within the limits Apple and Google enforce.

1. Install the plugin

The community plugin wraps SKStoreReviewController on iOS and the Play In-App Review API on Android:

npm install @capacitor-community/in-app-review
npx cap sync

This is native code, so it has to be in a store build before you can call it. Add it in your next release even if you plan to turn the prompt on later.

2. Request a review

import { InAppReview } from '@capacitor-community/in-app-review';

export async function askForReview() {
  try {
    await InAppReview.requestReview();
  } catch {
    // The prompt is best-effort. Never block the user on it.
  }
}

That is the whole API. You ask; the operating system decides whether to show anything.

The rules you cannot change

iOS (App Store)Android (Google Play)
How often it can showAt most 3 times per user in 365 daysA time-bound quota Google does not publish
Do you know if it showed?NoNo
Do you know what the user rated?NoNo
Custom rating promptsApple requires the system API for ratings prompts in the appAllowed, but you cannot incentivize or filter ratings

Two consequences. First, every request is precious; spending one on launch number three is a waste. Second, you cannot build a “how would you rate us?” screen that sends five-star users to the store and everyone else to a feedback form. Both stores prohibit steering or incentivizing reviews.

When to ask

Ask right after the user gets value, never in the middle of a task, and never on first launch. Good moments are specific to your app:

  • A workout is logged, an order is delivered, a document is exported.
  • The user completes a streak or a milestone.
  • A support conversation is marked as resolved.
  • The third or fifth successful session in a week.

And never:

  • Right after an error, a crash or a failed payment.
  • While a form is half filled in or a video is playing.
  • Straight after an update that changed something users complained about.

A small gate keeps the prompt honest:

import { Preferences } from '@capacitor/preferences';

const MIN_SUCCESS_EVENTS = 3;
const MIN_DAYS_BETWEEN_ASKS = 90;

export async function maybeAskForReview() {
  const { value } = await Preferences.get({ key: 'review' });
  const state = value ? JSON.parse(value) : { successes: 0, lastAsked: 0 };

  state.successes += 1;
  const daysSince = (Date.now() - state.lastAsked) / 86_400_000;

  if (state.successes >= MIN_SUCCESS_EVENTS && daysSince >= MIN_DAYS_BETWEEN_ASKS) {
    state.lastAsked = Date.now();
    state.successes = 0;
    await askForReview();
  }

  await Preferences.set({ key: 'review', value: JSON.stringify(state) });
}

Call maybeAskForReview() from your success moments, not from app startup.

Testing it

  • iOS: in development builds the prompt always appears, but submitting does nothing. In TestFlight it never appears. Test the trigger logic in development and trust the system in production.
  • Android: the review flow only works for apps installed from Google Play. Use an internal testing track or internal app sharing. The quota also applies while testing, so a prompt that showed once may not show again.

Tune the timing without a store release

The plugin is native. The decision of when to ask is not; it is plain TypeScript in your web bundle. That is exactly the part you will want to change once you see how ratings move: a different success event, a longer delay, a new exclusion after a bad release.

With OtaKit, those changes ship over the air. Adjust the thresholds, build, and release; users get the new logic on their next launch. You can even pause the prompt entirely within minutes after a rough release, which protects your rating when it is most exposed.

Ratings and release quality go together. The fastest way to lose stars is a bug that sits in production for a week while a fix waits in review. See deploying hotfixes over the air and rollback strategies.

Related docs