I’m proud of my app review track record.
It’s really simple to consistently get rated ~4.8* on the App Store.
Not easy as such. Simple.
Don’t believe me? I’ll demonstrate it at the end. Mathematically.
There are just 2 concepts to understand. One technical, one design:
You don’t get what you don’t ask for.
Identifying your wow moments.
Look, it’s table stakes to have an app without any bugs, crashes, or accessibility-related snafus.
Every time you frustrate your user from doing what they want, you risk a one-star rating that hobbles your average. I’m not here to discuss that.
You don’t get what you don’t ask for
Users aren’t often compelled to go to all the bother of opening the App Store, searching your app, and leaving a grumpy 1* review.
This rigmarole is reserved for especially crappy experiences.
Therefore, the majority of your app reviews should come when you ask for review. This is really easy via the StoreKit APIs in iOS.
SwiftUI
Asking for a review is trivial in a SwiftUI app. You simply invoke the requestReview environment value.
import StoreKit
@Environment(\.requestReview) var requestReview
@AppStorage("hasRequestedAppReview")
var hasRequestedAppReview: Bool = false
// ...
func requestReview() {
if !hasRequestedAppReview {
requestReview()
hasRequestedAppReview = true
}
}Here, requestReview() is the one-liner which does it all for you.
The environment property calls the
RequestReviewActioninstance directly, because internally it defines acallAsFunction()method.
I’m also adding user defaults here via @AppStorage — this prevents us asking multiple times in this context, so we don’t spam (and annoy) our users.
UIKit
The traditional approach to requesting app review is a little more verbose, but gives you more control (read: allows you to store your logic outside of a View, thank you very much).
Create a manager which finds a scene from your UIApplication singleton, then requests a review on that scene.
import StoreKit
public enum AppStoreReviewManager {
public static func requestReview() {
SKStoreReviewController.requestReviewInCurrentScene()
}
}
private extension SKStoreReviewController {
static func requestReviewInCurrentScene() {
if let scene = UIApplication.shared.connectedScenes
.first(where: {
$0.activationState == .foregroundActive
}) as? UIWindowScene {
requestReview(in: scene)
}
}
}For each app, Apple imposes a hard limit of 3 review requests per year, which should compel you to avoid wasting requests.
In practice, this means:
Avoid asking in the same context more than once.
‘Debounce’ requests by spacing them out by least a day, so a user isn’t overwhelmed if they go through multiple ‘wow’ paths of your app.
UserDefaults is our friend here, as it’s simple to store a ‘last request date’ and flags for each context from which we’ve already requested a review.
The wow moment
The flow for most apps looks like this:
Launch → Onboarding → Sign-up → Deliver Value
This value is why your users want the app — it’s having fun; a cool user experience; learning something; paying off the investment made during onboarding.
The important thing is it’s a wow moment. The user is the most happy with your app that they will ever be.
This is the point where you hit them with a review request.
The time-to-first-wow is a critical metric to optimise, since it has a direct impact on your app rating, user acquisition, and short-term retention. The optimal flow might look like this:
Launch → Onboarding → Deliver Value → Review Request → Sign-up
However, your product manager will probably insist you do this:
Launch → Onboarding → Sign-up → Deliver Value → Review Request
The critical path
There will always be a small number of users you simply can’t please, who were going to leave a 1* review anyway. This is inevitable.
Therefore you need to balance out this noise with a disproportionate number of users leaving a review.
This is a tricky balancing act:
On the one hand, you must ensure you request a review early on the critical path of your app, which a majority of users will see.
On the other hand, you need to maximise the probability that the users you ask are going to be happy enough to give an easy 5*.
You should make sure to embed the first wow moment in the critical path.
This is a lesson I learned the hard way:
I removed a review request from the critical path, replacing it with a request attached to a bigger wow moment.
Unfortunately, this bigger wow moment lay on a path which far fewer users experienced. This temporarily tanked our rating — because we were asking less overall, the low-level background radiation of 1* ratings became a higher proportion of total reviews.
Carbn: 4.8*
In Carbn, my former climate-action startup, the onboarding process was a lengthy 10-screen questionnaire about your eating, travel, and spending habits. From this information, we calculated your carbon footprint.
Somewhat surprisingly, more than 90% of the people who began the questionnaire finished it. We discovered that this is because the users made an investment which we promised to pay off.
In a typical bit of startup growth-hacking, we forced users to sign up after this questionnaire, but before they saw their results. Since they’d invested so much time already, this had phenomenally low drop-off.
After burning this small amount of goodwill, we showed the user a beautiful, slow-running animation which revealing their carbon footprint, alongside several nifty graphs to break it down and benchmark it against other users.
5 seconds into this — enough time to be awed, but not enough time for the novelty to wear off — we asked for an app review.
This drove an average review score of 4.8* which, at the time, was the best rating for a climate action app. Unfortunately, this wasn’t enough to convince prospective seed investors in the hellscape that was the 2022 venture capital environment.