# Appirater: A Configurable Review Prompt for iOS Apps, With a Built-In Trade-Off

> Appirater is a small Objective-C utility that schedules App Store review requests based on usage thresholds. It now leans on SKStoreReviewController when available, which changes how often the prompt actually appears.

**arashpayan/appirater** — GitHub describes it as A utility that reminds your iPhone app's users to review the app.. The repository metadata lists Objective-C as its primary language. This article stays within the project description and details documented in the GitHub repository README.

- Repository: https://github.com/arashpayan/appirater
- Website: http://arashpayan.com/blog/2009/09/07/presenting-appirater/
- Stars: 4,586 · Forks: 831
- Language: Objective-C
- License: not declared
- Published: 2026-08-13 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/arashpayan-appirater

## What Appirater Actually Solves

Appirater addresses a narrow problem: getting an App Store review request in front of a user at a moment that is not the first launch. Without a utility like this, an app either asks immediately, which annoys new users, or never asks, which forfeits a rating. The class is designed for iPhone apps running iOS 4.0 or later, which means it predates the modern review API. The README describes it as a class you can drop into any iPhone app, and the target audience is an Objective-C developer who wants a configurable reminder without building the scheduling state machine themselves. The library is not a rating service and it does not collect feedback. It only decides when to show a prompt and then hands off to the App Store or to SKStoreReviewController. That narrow scope is its strength and also its limit.

## The Mechanism: Thresholds and State

Appirater works by tracking three counters and two time intervals. The README shows configuration methods: setAppId, setDaysUntilPrompt, setUsesUntilPrompt, setSignificantEventsUntilPrompt, and setTimeBeforeReminding. The app calls appLaunched:YES in application:didFinishLaunchingWithOptions: and appEnteredForeground:YES in applicationWillEnterForeground:. Each launch increments the use count, and each call to userDidSignificantEvent:YES increments a separate count. The prompt appears only when all configured conditions are met. For example, the README gives a production setup where the request shows only after 5 launches and 7 days, with significant events disabled via -1. The timeBeforeReminding value controls how long to wait before showing the prompt again after the user dismisses it. The state is presumably persisted, though the README does not say where. The logic is a simple AND across conditions, not an OR. That means setting usesUntilPrompt to 0 and daysUntilPrompt to 5 shows the prompt after 5 days, as the README confirms, because the launch count condition is effectively disabled.

## Getting It Running: CocoaPods and Delegate Calls

The README gives a clear integration path. Add pod "Appirater" to your Podfile. Then configure it in your app delegate. The minimum setup is three calls: setAppId with your Apple-provided ID, appLaunched:YES at the end of application:didFinishLaunchingWithOptions:, and appEnteredForeground:YES in applicationWillEnterForeground:. The README also shows an optional call to userDidSignificantEvent:YES for events like completing a purchase or finishing a level. The example sets debug:YES during development to force the prompt on every launch, and debug:NO in production. The README warns that all configuration must be set in application:didFinishLaunchingWithOptions: for production, which implies that changing settings later in the app lifecycle may not take effect. There is no mention of a storyboard or xib, so the integration is purely programmatic.

## The SKStoreReviewController Shift

The most important design change in Appirater is its automatic use of SKStoreReviewController on iOS 10.3 and later. The README states that Appirater automatically uses SKStoreReviewController if available, and that you must manually link StoreKit. This changes what Appirater does. Instead of sending the user to the App Store page, the system presents an in-app rating dialog. The README is explicit that SKStoreReviewController automatically limits the number of impressions, so the dialog may appear less frequently than your configured conditions suggest. This is a real trade-off. Your setDaysUntilPrompt and setUsesUntilPrompt still gate the first appearance, but Apple's own frequency cap can suppress subsequent prompts. If you need a prompt every N launches, Appirater cannot guarantee that on modern iOS. The library becomes a scheduler, not a presenter. That is a meaningful shift from the original purpose, and any developer adopting it should understand that the old behavior of always opening the App Store page is gone on newer OS versions.

## A Genuine Limitation: No Control Over System Limits

The README's note about SKStoreReviewController is the clearest limitation. The library cannot override Apple's impression limits, so the prompt might not show even when your counters say it should. This is not a bug in Appirater; it is a platform constraint. Another limitation is that the README does not document how the counters are stored or reset. If you reinstall the app, the counters likely reset, which means a user who reinstalls will be prompted again after meeting the thresholds. There is also no mention of handling the case where the user has already reviewed the app. The library does not appear to check whether the user has already submitted a review, so it may prompt again. The README also does not list any delegate methods to customize the alert text or buttons, only the class methods shown. If you need a different wording or a custom UI, you would have to fork the code.

## The Wrong Tool for Modern Review Management

Appirater is not the right choice for an app that targets only iOS 10.3 and later and wants to rely entirely on SKStoreReviewController. In that case, you can call SKStoreReviewController directly and skip the extra dependency. The library adds a configuration layer, but Apple's own limits make that layer less meaningful. The README even implies this by saying Appirater is used only to decide when to show the dialog. If your app needs to respect user opt-out or track review requests for analytics, Appirater does not provide that. The README mentions no analytics hooks or user preference storage. A developer building a modern app with a custom rating flow would need to write that logic themselves. The library is best suited for a legacy codebase that already uses Objective-C and needs a quick, MIT-licensed reminder without new dependencies beyond StoreKit.

## Maintenance and License Reality

The repository shows no recent releases and no archived status, but the last copyright year in the README is 2017. That suggests the project is dormant. The README lists a MonoTouch binding port, but notes that the maintainer does not know how closely it tracks the Objective-C version. For a developer, this means you should expect to maintain the code yourself. The license is MIT/X11, which allows modification and sharing, and the README explicitly encourages contributing improvements back. There is no mention of a formal support channel beyond Stack Overflow with the appirater tag. The dependency on StoreKit is manual, so you must remember to link it. The lack of an official release process means you will likely pull the source directly from GitHub. The code is small enough that a single developer can audit it, but the absence of maintenance is a cost you should weigh before adopting.

## Conclusion

Adopt Appirater if you maintain an older iOS app (iOS 4.0 or later) and want a simple, MIT-licensed way to schedule review prompts without writing your own logic. Skip it if you need precise control over prompt frequency, because SKStoreReviewController imposes its own limits that override your settings. Before adopting, verify that the library still compiles with your current SDK, check the Appirater.h header for any methods not shown in the README, and confirm that linking StoreKit manually is acceptable in your build. The project appears unmaintained, so budget for your own fixes if you use it.

## FAQ

### How do I add Appirater to an iPhone app?

Add `pod "Appirater"` to your Podfile, then call `[Appirater setAppId:@"yourAppId"]` at the start of `application:didFinishLaunchingWithOptions:`, `[Appirater appLaunched:YES]` at the end of it, and `[Appirater appEnteredForeground:YES]` in `applicationWillEnterForeground:`. The library targets iOS 4.0 or later.

### What does setDebug do in Appirater?

Setting `[Appirater setDebug:YES]` makes the rating request show on every app launch, which is what you want while testing. In production you must set `[Appirater setDebug:NO]`, otherwise every user sees the dialog on every launch. The README flags both values explicitly.

### How do I control when the Appirater prompt appears?

With `setDaysUntilPrompt`, `setUsesUntilPrompt` and `setSignificantEventsUntilPrompt`, which combine with AND rather than OR. Set one of them to 0 to disable that condition. `setTimeBeforeReminding` controls the cool-off period after the prompt has been shown.

### Does Appirater use SKStoreReviewController?

Yes, automatically when it is available, which means since iOS 10.3. You have to link StoreKit in your app manually. When it is used, Appirater only decides when to show the dialog, and the system limits impressions, so the dialog may appear less often than your configured conditions suggest.

## Sources

- [Official documentation](http://arashpayan.com/blog/2009/09/07/presenting-appirater/)
- [Official README](https://github.com/arashpayan/appirater#readme)
- [Project repository](https://github.com/arashpayan/appirater)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/arashpayan-appirater