SKStoreReviewController and requestReview: Asking for Ratings

Ratings move App Store search and conversion, and the system prompt that asks for them is one line of code. That makes it easy to call in the wrong place, at the wrong time, with the wrong API. SKStoreReviewController is the name most tutorials still use, but Apple has deprecated it. This guide covers the current API as of 23 April 2026, the limits Apple documents, when to ask, and how a rating prompt differs from asking for feedback.

Shipping on Android too? The Google Play version of this guide is Google Play In-App Review API: Asking for Ratings on Android.

The short version

• In SwiftUI, read the requestReview environment value and call it. In UIKit, call AppStore.requestReview(in:) with a window scene.
• SKStoreReviewController is deprecated from iOS 18, in favour of RequestReviewAction.
• The system decides whether the prompt appears. For people who haven't rated your app on that device, it appears at most three times in a 365-day period.
• Never call it from a button. For a "Rate this app" button, link to your product page with action=write-review.
• A rating prompt has no reply channel. Give people a separate way to tell you what they want.

The API, then and now

As of 23 April 2026, Apple's StoreKit documentation lists these entry points:

Sources: Apple's pages for SKStoreReviewController and RequestReviewAction. If your app supports iOS 16 or later, you don't need SKStoreReviewController at all.

SwiftUI

Apple's sample, Requesting App Store reviews, reads the environment value, waits until the person has completed a task several times, skips versions it has already asked about, and adds a short delay so the prompt doesn't interrupt. Here is the same idea for a fictional hiking app, asking after a hike summary appears:

import StoreKit
import SwiftUI

struct HikeSummaryView: View {
    @Environment(\.requestReview) private var requestReview
    @AppStorage("completedHikes") private var completedHikes = 0
    @AppStorage("lastVersionPromptedForReview") private var lastVersionPrompted = ""

    var body: some View {
        SummaryContent()
            .task { await askForReviewIfAppropriate() }
    }

    private func askForReviewIfAppropriate() async {
        completedHikes += 1
        let version = Bundle.main.object(
            forInfoDictionaryKey: "CFBundleShortVersionString"
        ) as? String ?? ""
        guard completedHikes >= 4, version != lastVersionPrompted else { return }

        try? await Task.sleep(for: .seconds(2))
        requestReview()
        lastVersionPrompted = version
    }
}

UIKit

import StoreKit

if let scene = view.window?.windowScene {
    AppStore.requestReview(in: scene)
}

The limits Apple documents

Apple's documentation for RequestReviewAction sets out how StoreKit decides, as of 23 April 2026:

• If the person hasn't rated or reviewed your app on this device, StoreKit shows the request at most three times within a 365-day period.
• If they have, StoreKit shows it again when the app version is new and more than 365 days have passed since their previous review.
• Because the call may not show anything, don't make it in response to a button tap or other user action.
• In development, the prompt always appears, so you can test the flow. In builds distributed through TestFlight, the call has no effect.
• People can turn off review requests on their device altogether.

Two rules from elsewhere matter too. The App Review Guidelines, 5.6.1, tell you to use the provided API to prompt for reviews, and say Apple will disallow custom review prompts. And for a permanent "Rate this app" entry in Settings, Apple suggests linking to your product page with the query parameter action=write-review, which opens the page where people can write a review.

When to ask

Apple's Human Interface Guidelines on ratings and reviews give the timing advice, as of 23 April 2026:

• Ask after people have shown engagement, such as finishing a level or a significant task. Avoid asking on launch or during onboarding, before they have formed an opinion.
• Don't interrupt. Look for natural breaks, not the middle of a task.
• Don't pester. Apple suggests allowing at least a week or two between requests, and asking again after more engagement.

To that we would add: don't ask right after something went wrong. A sync error, a failed purchase or a crash on the previous launch are all reasons to wait. And in a hiking app, "after the hike" beats "during the hike" every time.

Asking for a rating is not asking for feedback

The rating prompt does one job: it collects stars, and sometimes a written review, for the App Store. It doesn't give you a way to reply in the app, a way to ask a follow-up question, or a way to tell the person later that you built what they wanted. Replies to reviews happen in App Store Connect, in public.

So the "I'd give five stars if it had offline maps" thought needs somewhere else to go. Apple's page on ratings, reviews and responses makes a related point: make your support contact easy to find, so people have a direct route to you before frustration turns into a poor review.

You may be tempted by a pre-prompt that asks "Are you enjoying the app?" and sends unhappy users to a feedback form and happy users to the rating prompt. We would avoid that. Guideline 5.6.1 rules out custom review prompts, and a filter in front of the system prompt sits uncomfortably close to that line. A safer pattern is to keep two permanent entries side by side in Settings: "Rate Trailmate" (the write-review link) and "Suggest a feature".

How FeedbackKit fits in

FeedbackKit is that second entry. It puts a feature request board inside your app, where users post what they want, vote on other people's ideas and comment. It doesn't touch your App Store ratings and doesn't show the rating prompt. It gives the wish list a place to go that isn't a three-star review.

Here is how that looks in FeedbackKit, with sample data from a fictional hiking app:

A vote tells you more than a star rating does. You know which feature, how many people want it, and, if your app passes it through the SDK, how much monthly revenue sits behind it. The Swift SDK's screens are SwiftUI, so they sit next to your review code on iOS 26, macOS 26 and visionOS 26 or later. See the Swift docs, or Kotlin and Flutter for your other apps. When a request moves to a status on the project's email list, the person who asked is emailed about it if they gave an address, as covered in our guide to release notes.

If you want the wish list in one place instead of scattered through reviews, start free.