Most indie iOS apps have a ratings problem. Not because their users are unhappy, but because the prompt arrives at the wrong moment, or never arrives at all.

This matters more than most developers realize. Ratings aren’t just social proof. They’re a conversion signal Apple uses to decide whether your keyword rankings are worth defending.

Here’s how to fix it without guessing or breaking Apple’s rules.

The ratings problem is not what you think it is

The instinct most developers follow is one of two extremes: either they never ask for a review and hope it happens organically, or they beg for it in a popup that interrupts whatever the user was doing.

Neither works well.

The problem is timing and context. A user who just launched your app for the first time and has not done anything yet is not ready to rate it. A user who just hit an error is definitely not ready. A user who just completed something meaningful, like a workout, a quiz, or a milestone, is the right target at the right moment.

From Marteso’s current app data: Pi Digits has 1 US rating at 5 stars. RowTally and CalcBlitz each show 0 ratings. These are not bad apps. They’re apps that have not solved the prompt timing problem yet.

Apple’s rules, plainly stated

Apple gives you one legitimate tool: SKStoreReviewController.requestReview(). You call it in code; Apple controls how the prompt looks and handles the response. You cannot override the dismiss behavior. You cannot incentivize a review. You cannot ask inside a form or transaction.

Apple limits this to three requests per year, per device. That ceiling sounds high until you realize most indie apps burn one or two requests on bad moments, like right after onboarding or mid-session, and the third never shows up in a useful context.

Three requests a year means three deliberate decisions. Treat each one like a finite resource.

The two timing windows that work

There are two moments where a review request has a meaningful chance of getting a positive response.

The first-run delight moment is the first time a user accomplishes the core job the app was built for. Not the onboarding tutorial. The actual thing. For Pi Digits, that is completing a pi recall challenge. For RowTally, it is saving a completed row count. For CalcBlitz, it is finishing a timed calculation.

The user has just validated that the app does what they needed. That’s the right moment.

The milestone moment is when a user hits a meaningful progress point: a streak, a personal best, or a completion count. For Pi Digits, it might be recalling 10 digits for the first time. For a habit app, it might be a 7-day streak.

Milestones work because the user is already in a positive emotional state. You’re not interrupting them. You’re acknowledging something they just did.

Avoid asking on cold launches, error states, or first sessions before the user has done anything.

Why ratings velocity feeds into keyword rankings

This is the part most ASO guides skip.

Ratings are not just a trust signal for users browsing the App Store. They’re a conversion-quality signal for Apple. When Apple ranks your app for a keyword, it watches whether users who find your app through that search actually download it. If they do not, the ranking erodes.

An app with 1 rating is harder to trust than an app with 200 ratings at a similar score. When a potential user lands on your product page and sees one rating, the psychological friction is real, and Apple can observe that in conversion data.

For indie apps targeting competitive keywords, that friction is often the invisible ceiling on rankings. The keyword work is right. The metadata is right. But the product page does not convert well enough to hold the rank.

Getting to a credible rating volume, even 20 to 50 ratings, meaningfully reduces that friction.

A practical prompt implementation

Here’s the structure I’d recommend for most indie apps.

Identify one delight event in your app. This is the in-app action that means a user has gotten real value. Write it down before you write any code.

Implement a soft counter. Count how many times a user has hit that event. On the third or fifth occurrence, call requestReview(). Don’t prompt on the first session.

Add a milestone trigger. Pick one progress milestone, such as a streak, personal best, or completion count, and add a second requestReview() call there. This gives you two contextually appropriate moments per user without burning all three yearly slots.

Never ask inside a flow. The review prompt should only appear on a natural pause: after a game ends, after a workout is saved, after a route is completed. Never mid-task.

What not to do

Do not buy reviews. Apple detects patterns and removes them. The ranking signal from fake reviews is temporary; the penalty risk is not.

Do not send push notifications asking for a review. This is against Apple guidelines and trains users to mute your notifications.

Do not use third-party review-gating services that filter users before sending them to the App Store prompt. Apple’s guidelines prohibit routing only positive sentiment to the prompt.

Do not add a persistent “Rate us” button in your settings menu and call it a strategy. It is not a strategy. It is a fallback for users who would have rated you anyway.

How long before you see results

Ratings volume is a slow build. The fastest way to accelerate it is to nail the timing windows above and ship a build that calls requestReview() correctly.

For most indie apps, going from 0 to 20 ratings takes weeks, not days, depending on your active user base. But the compounding effect matters: higher ratings count improves product-page conversion, which improves the conversion signal for your ranked keywords, which makes those ranks easier to hold.

The ASO system rewards consistency. Ratings are part of that system.