Automating App Store Rating Requests: Trigger Logic and Timing Rules
Most apps ask for a review at the wrong moment — either immediately after install or right in the middle of a task the user was trying to finish. Both approaches produce low response rates and, worse, trigger one-star reviews from users who were interrupted at the worst possible time. The fix isn't to ask less often. The fix is a proper workflow automation layer that fires the prompt only when specific behavioral conditions are true and suppresses it when they're not.
This post walks through the trigger logic, timing rules, and suppression conditions you need to build a rating-request system that actually works — without running into App Store or Google Play policy violations.
Why Rating Prompts Fail Without Automation Logic
A static timer — "show prompt 3 days after install" — misses the point entirely. A user who installed three days ago but only opened the app once is not a satisfied user. Asking them to rate the app is a coinflip at best.
The underlying problem is that time is a proxy for satisfaction, and it's a bad one. What you actually want to measure is signal of success: did the user complete the core value action? Did they come back? Did they finish a session without crashing?
When you build a workflow automation system around those signals instead of a calendar, your rating prompts go to users who have actually experienced value. That changes the distribution of responses.
Beyond response quality, there are hard platform constraints:
- Apple (SKStoreReviewRequest): iOS limits your app to 3 rating prompts per 365-day period per device. Exceed that limit in code and the system simply won't show the dialog — but you've still "spent" a request attempt. Apple controls the UI; you cannot customize the prompt.
- Google Play (In-App Review API): Google's quota is undocumented but enforced. Their docs explicitly say "do not show the review dialog in response to a user action" — meaning you can't trigger it from a button tap. It must emerge from automated logic.
Getting these right requires a real automation architecture, not a setTimeout call.
The Three Layers of a Rating Request System
Think of it as three stacked gates. A prompt only fires when all three pass.
Layer 1: Behavioral Triggers (Positive Signal)
This is the "user has experienced value" gate. Define one or more of these conditions in your product analytics layer:
- Completed the core value action at least N times (e.g., completed a workout, made a purchase, sent a message)
- Reached a meaningful milestone (streak day, level, first successful delivery)
- Finished a session that lasted longer than a minimum threshold
- Returned to the app after at least one previous session
Pick the trigger that maps closest to your app's "aha moment." For a marketplace like My Home Delivery — where the value is a completed delivery — triggering after the first successful delivery confirmation is the right event. For a fitness app like MyPace, it might be completing three consecutive workout sessions.
Layer 2: Timing Rules (Minimum Gaps)
Even after a user hits the behavioral trigger, you don't fire immediately. Timing rules are the "not right now" gate:
| Rule | Recommended Value |
|---|---|
| Minimum days since install | 3–7 days |
| Minimum days since last prompt | 60–90 days |
| Minimum sessions before first prompt | 3–5 sessions |
| Cooldown after a crash or error event | 7 days minimum |
| Time since last app update | 1–3 days (let them settle) |
The 60–90 day gap between prompts is critical for iOS where you only get 3 shots per year. Burn them in the first month and you've lost access to users for the rest of the period.
Layer 3: Suppression Logic (Negative Signal)
This is where most implementations fall short. Suppression logic blocks the prompt even when layers 1 and 2 would allow it:
- User is mid-session on a critical flow (checkout, form submission, onboarding step)
- A crash occurred in the last N days
- User submitted a support ticket in the last 30 days
- User downgraded or churned (subscription apps)
- User explicitly dismissed a previous prompt without rating
The support ticket suppression is particularly important. A user who just contacted support about a broken feature is not a candidate for a rating prompt — regardless of what the behavioral trigger says.
Implementing the State Machine
The cleanest implementation stores rating eligibility as a state machine on the backend, not just in local device storage. Local storage works for simple apps but breaks down when you need cross-device consistency or when you want to analyze prompt performance in aggregate.
Recommended state fields (stored per user, not per device):
rating_state: {
prompt_count_ttm: int, // prompts shown in trailing 12 months
last_prompt_at: timestamp,
last_dismissed_at: timestamp,
last_rated_at: timestamp,
behavioral_trigger_met: bool,
suppression_active: bool,
suppression_reason: string, // "crash", "support_ticket", "mid_flow"
eligible_after: timestamp // computed field
}
On each app session start, your client requests the current eligibility state from your backend. The backend runs the gate logic and returns a boolean plus an optional eligible_after timestamp your client can use to schedule a local check.
This architecture also means your product team can adjust timing rules and behavioral thresholds without a new app release — a significant operational win.
If you want this kind of automation layer built into your app from the start, the Semnexus app development team can wire it into your architecture during the build phase rather than retrofitting it later.
Platform-Specific Implementation Notes
iOS (SKStoreReviewRequest)
Call SKStoreReviewRequest.requestReview(in:) (SwiftUI) or SKStoreReviewRequestAPI only after your gate logic returns true. Apple's system will decide whether to actually show the prompt based on its own internal factors — your logic controls when you attempt the request, not whether the dialog appears.
Keep a local counter synced with your backend. If your backend says prompt_count_ttm >= 3, don't even make the API call.
Google Play (In-App Review API)
Use ReviewManagerFactory.create(context) to get a ReviewManager, then call requestReviewFlow() to prefetch the review object before you actually need it. Prefetch at session start so you're not introducing latency at the moment of trigger.
Google's quota enforcement is opaque — the API call won't fail, it will just not show the dialog. Your backend state machine should still enforce conservative timing to avoid burning quota on ineligible sessions.
Monitoring and Iteration
Once the system is live, track these metrics to tune your trigger conditions:
| Metric | What It Tells You |
|---|---|
| Prompt impression rate | % of eligible users who actually see the dialog |
| Rating completion rate | % of impressions that result in a rating |
| Average rating of prompted users | Whether your trigger is catching satisfied users |
| Suppression rate by reason | Which suppression rules are firing most |
| Prompt count distribution | Whether you're burning iOS quota too fast |
In our engagements, the biggest lever is typically the behavioral trigger threshold — teams often set it too low (one session, one action) and end up prompting users who haven't fully experienced the product. Tightening that threshold typically lifts average rating more than any other single change.
If you're thinking about how automated systems interact with more complex decisioning logic, the patterns covered in AI Agent Escalation Logic: When to Hand Off to a Human and How apply here too — suppression logic is fundamentally an escalation decision.
Frequently Asked Questions
Can I offer an incentive to get users to leave a review?
No. Both Apple and Google explicitly prohibit incentivizing reviews. Violating this can result in app removal. Your only lever is timing — prompt users who've already had a positive experience.
What happens if I call SKStoreReviewRequest more than 3 times in a year on iOS?
The system silently suppresses the dialog. The user never sees it, and you don't get an error. This is why your backend state machine needs to enforce the limit independently.
Should I direct unhappy users to a support channel instead of the rating prompt?
Yes — and this is a legitimate pattern. Before triggering the rating prompt, you can ask a single-question gate: "Are you enjoying the app?" Route satisfied users to the rating prompt and dissatisfied users to your support channel or feedback form. This is allowed by both platforms as long as the rating prompt itself isn't artificially filtered after the fact.
How do I handle users who dismiss the prompt without rating?
Log the dismissal timestamp and reset their eligibility clock. In our implementations, we treat a dismissal as a 90-day suppression at minimum. Don't re-prompt aggressively — users who dismiss once are telling you something.
Does the Google Play In-App Review API work for all users?
No. It requires the user to be signed into a Google account on the device, and the device must have the Play Store installed. Sideloaded APKs and enterprise deployments won't see the dialog.
How do I test this system without burning live quota?
On iOS, use StoreKit testing in Xcode — it bypasses the 3-per-year limit in development. On Android, use the FakeReviewManager provided in the Play Core testing library. Your backend state machine can also accept a test_mode flag that bypasses timing gates for QA runs.
Building rating request automation correctly takes maybe a sprint — but it's one of the highest-leverage pieces of workflow automation in mobile because it compounds over time. Every update that ships to satisfied users is another opportunity to prompt them, and a well-tuned trigger system makes sure you don't waste those windows.
If you're building a new app or retrofitting this into an existing one, the Semnexus app development team can help you architect the state machine alongside your core product — and if you want to talk through your specific trigger logic and timing rules, book a 30-minute call and we'll get into the details.
