iOS In-App Review Prompt: When and How to Ask for Ratings

Quick answer: On iOS you ask for ratings with Apple's system prompt, called through StoreKit: the SwiftUI requestReview environment action or AppStore.requestReview(in:) in UIKit. Your app only requests it; the system decides whether it appears and shows it at most three times in 365 days per person. Ask right after a successful moment, never at launch or from a button tap.

The prompt is a standard system alert. People tap one to five stars and can write an optional review without leaving your app. You can't change its design, and you get nothing back: the call doesn't tell you whether the alert appeared or which rating someone gave.

Apple's StoreKit documentation spells out the display rules:

• If the person hasn't rated or reviewed your app on that device, StoreKit shows the prompt a maximum of three times within a 365-day period.
• If they have already rated or reviewed it, the prompt can return only for a new app version and only when more than 365 days have passed since their previous review.
• People can switch off rating requests for every app in their App Store settings, in which case your call silently does nothing.

Because of these rules, calling the API is a request, not a command. That is why your own timing logic matters more than the API call itself.

There is also a policy side. App Store Review Guideline 5.6.1 tells developers to use the provided API to prompt for reviews and says Apple will disallow custom review prompts. A homemade star screen that imitates the system alert is a rejection risk.

Apple has replaced the original SKStoreReviewController methods with newer StoreKit APIs. Here is how they line up today:

If your deployment target is iOS 16 or later, use the SwiftUI action or AppStore.requestReview(in:). If you still support iOS 15, keep the deprecated scene-based call behind an availability check.

The SwiftUI version in four steps

1. Add import StoreKit to the view that will ask.
2. Declare @Environment(\.requestReview) private var requestReview in that view.
3. When your own conditions are met, call requestReview() on the main actor.
4. Record that you asked (for example, the current bundle version) so you never ask twice for the same version.

In UIKit, get the active UIWindowScene from your view's window and pass it to AppStore.requestReview(in:). Everything else stays the same.

Gate the call with your own logic

Apple's sample project shows a sensible pattern. It only asks when three conditions are true: the app hasn't prompted for the current bundle version, the person has completed the core task at least four times, and they have paused on the success screen for a few seconds. Apple notes the number four is arbitrary; pick a threshold that matches how often people complete your main task. The sample stores its counters with @AppStorage, and UserDefaults works just as well in UIKit.

Apple's Human Interface Guidelines say to ask only after people have demonstrated engagement, to avoid first launch and onboarding, to avoid interrupting a task, and to consider waiting at least a week or two between requests. The StoreKit sample adds two more rules: don't ask immediately at launch, and don't ask as the result of a user action.

In practice, the best moment is the second after something went right:

A few extra guardrails keep you out of trouble:

• Never ask right after a crash, failed purchase, sync error or paywall.
• Require both time and depth, for example at least three sessions across five days plus one success event.
• Ask once per version at most, and skip versions that only fix bugs people complained about.
• Don't put a "Do you like the app?" screen in front of the system prompt to filter out unhappy users. Apple disallows custom review prompts, and Google's in-app review rules forbid this kind of pre-question outright. Offer a permanent "Send feedback" option instead.

You can't call the review prompt from a button, because the system may ignore the request and the button would appear broken. Apple's documentation covers this case: add a persistent link to your App Store product page in your settings or About screen, and append the query parameter ?action=write-review to your product page URL. That opens the App Store directly on the write-a-review sheet.

A good settings row reads "Rate [App Name] on the App Store" and sits next to "Send feedback" and "Contact support." People who want to praise you get a one-tap path, and people with a problem get routed to you instead of a one-star review.

The prompt behaves differently depending on how the app was installed, which confuses many teams during QA:

Since TestFlight shows nothing, test your gating logic separately. Log each condition (session count, last prompted version, success events) and write unit tests for the function that decides whether to ask. Then confirm the actual alert in a debug build. For more on beta builds, see the TestFlight guide.

Your summary rating appears in search results and on your product page, and it's calculated separately for each country or region. If an old version earned poor ratings, Apple lets you reset the summary rating when you release a new version, though it recommends doing so sparingly. The details are in how App Store ratings work.

Ratings also feed your creative. A strong average or a real, current review quote can become a social-proof screenshot; see social proof in App Store screenshots for the accuracy rules. And when reviews do arrive, answer them: replies are public, and people are notified when you respond. Our guide on how to respond to app reviews has templates.

For the full picture beyond the prompt, including support funnels and what the rules forbid, read how to get more app reviews. If you also ship on Android, the Google Play In-App Review API works on a similar idea but with an undisclosed quota.