Fairly often, our clients ask if we should include a “Rate this App” function in their iOS apps. The simple answer is yes – a healthy stream of ratings and reviews is a great thing for increasing downloads of your app.

However, there are enough subtle pitfalls around the relevant APIs and App Store Guidelines that it can be easy to get this wrong. Conversations about app ratings often devolve into debates about what Apple will or won’t allow, and it’s hard to remember the exact details and limitations.

So, for your reference and possible enjoyment: the dos and don’ts of iOS app rating functionality in 2019.

Two APIs, both alike in utility

There are two ways a user can leave a rating in an iOS app. The ideal way is the in-app star rating dialog available in iOS 10.3 and later. Using the SKStoreReviewController API, your app can request that iOS show this prompt.

This is a nice way to let users rate your app, and in most aspects is the best way. However, this API has one serious caveat: an app can’t always show this prompt, it can only request it to be shown. If your app has shown this prompt 3 times in the last year, or your customer has turned off review prompts on their device, then nothing will happen when you request this prompt.

Sometimes, not showing a prompt is totally fine. In the case of a “drive-by” request for a rating, the user won’t notice or care if the prompt doesn’t show. However, it’s a serious problem if somebody taps a button that says “Rate this app” and nothing happens. If you’d like users who are browsing your Settings or More page to have the option of rating your app – which you would like, since it’s good for your business – you need to wire up a button that reliably works.

Given that, in cases like this where you’re reacting to a user tap, developers need to use the older rating mechanism: loading a review page in the App Store app. This requires using the itms-apps:// URL for your app, which jumps users out to write a review.

The App Store link is a reliable mechanism, but it has two serious downsides:

1. Jumping out to the App Store app is a worse experience than the in-app rating
2. The App Store review guidelines ask that apps “Use the provided API to prompt users to review your app” and threaten to “disallow custom review prompts”.

These downsides make many developers hesitant to use the older functionality, even though it’s the only way currently (as of iOS 13) to add a reliable button that lets users rate your app.

Luckily, Apple’s App Review has consistently respected the difference between a “prompt” for ratings where users are interrupted – in which case Apple expects us to use the throttled in-app dialog – and a user-initiated choice to rate, where jumping to the App Store is fine. Countless apps continue to successfully use the itms-apps:// flow to enable a “Rate our app” function without raising the ire of App Review, and all is well.

Getting clever

Beyond the routine practice of wiring up a simple “Rate this app” function that goes to the App Store, there are some more advanced approaches to streamlining how users are asked for reviews. These may may make sense for your app, depending on your business and how willing you are to risk running afoul of the App Review Guidelines.

Dual wielding

If you want to offer a “Rate this app” button but still want the nicer UX of the in-app dialog, you can take the clever approach that Overcast does: the first time a user taps the button, they use SKStoreReviewController to request a review prompt, which might do nothing, but will usually work. If a user taps again, they jump out to the App Store review page which always works.

You could go a bit further with this by tracking if you’ve called for the review prompt 3 times in the last year, switching between the two APIs as needed, and maintaining this logic if Apple changes the review prompt throttling in the future. Even with the simple dual approach described above though, your users will get the nicer UX most of the time, but still minimize the cases where your “Leave a rating” button feels broken.

Is this a good time?

If you’re willing to interrupt users with an unexpected rating prompt, it’s worth putting serious consideration into when you want to do this – and how frequently you want to bother people.

The common-sense approach is to only prompt a user for a rating once it seems likely your app has delivered them real value. Usually you want to wait until they’ve used the app multiple times, and had a modicum of success exercising its features.

In terms of frequency, although you can in theory prompt 3 times a year, it’s worth seriously considering if you dial that back, resulting in less annoyed customers and thus more positive ratings when people do see a prompt.

Are you enjoying this app?

A lot of larger apps, especially SaaS products, will add a custom prompt along the lines of, “Are you enjoying this app?” This can be great for detecting unhappy customers and directing them to customer care to help turn them into happy customers, and it also lets you encourage happy users to rate or review the app on the App Store.

The danger here, however, is that Apple is almost certainly not fond of apps only asking happy users for reviews. This behaviour could easily be construed as a “custom review prompt” as barred by the App Review Guidelines, or more seriously could be considered “manipulating reviews,” which is a bannable offence. From the Guidelines (emphasis mine):

If we find that you have attempted to manipulate reviews, inflate your chart rankings with paid, incentivized, filtered, or fake feedback, or engage with third-party services to do so on your behalf, we will take steps to preserve the integrity of the App Store, which may include expelling you from the Developer Program.

While we have not heard of an app getting banned or even rejected by App Review for only asking happy customers for reviews, doing so would be well within the wording of the guidelines and is the kind of sudden policy change App Review has made in the past.

On the other hand, this would be a hard thing to enforce – while a reviewer might be able to catch some very linear conditional-review flows, it would be fairly easy for an app to simply take note of happy and unhappy users and later “randomly” prompt just the happy ones for reviews.

Overall, our current recommendation on conditional review prompts is to tread carefully and thoughtfully.

In review

Although letting people rate your app seems like a minor consideration, a tiny detail to stick in Settings in the run-up to 1.0, there is actually a lot of thought and consideration that can go into good rating flows. If you’re in the thick of getting an app shipped you may not want to get bogged down in all the ins and outs of this, but once your app is live and you’re working to scale your user base, refining these rating flows can be a great way to spread the word of your app and what makes it great.