Android developers could respond to user reviews on Play Store for years now. They could even share their contact information to provide additional support. iOS developers have been asking for a similar, if not better, option for apps on the App Store too. Our prayers seem have answered with iOS10.3, which is in beta currently. However, in typical Apple style, the problem has been tackled differently.
With iOS 10.3, Apple will provide two options for developers: embedded app review dialog and also an option to respond to customer reviews.
Embedded app review dialog
Historically, app developers have placed dialogs at regular intervals in the app. These helped users to either give a broad feedback immediately (‘enjoying the app?’) or rate the app at the app store page. Mostly, developers preferred to direct the user to the app store and allow them to rate and review through a single dialog. The experience was seamless enough but it had a disadvantage of having to come back to the original app after the review. This might have discouraged a lot of users from rating the app in this fashion. But with the embedded review dialog that hurdle is removed now. We are pretty sure that the review dialog (SKStoreReviewController) would provide rating as well as review comment section to be submitted in one shot. However, what needs to be seen is whether this will involve an iTunes account authentication flow. If so, it could discourage the user from providing the review. But since the user would have authenticated already at the time of download (though this authentication expires after sometime) this may not be required again.
It also remains to be seen as to how many developers use this feature. Providing an embedded way to review the app increases the potential of both positive and negative reviews. So developers integrating this will have an additional pressure to improve the quality of the app since any bad experience can easily draw negative reviews. Although Apple has provided this feature, Apple still tightly controls the availability and frequency. An app can put only 3 review dialogs per year (the counter does not get reset each time the developer updates their app). From the beta documentation of this feature it appears that the API will control this aspect. But it’s strongly recommended that developers use their own business logic to determine when to put out the dialog. It is also not clear whether the new APIs will allow you to determine if a customer has already provided a review. This would give better control to the developers to decide when to put the dialog. Since it cannot be determined whether the system will put up this dialog or not it is strongly advised that its not used in response to call-to-action experiences such as buttons. The integration of this feature should be tightly embedded into the flow of your app. Best places to put this is when the app determines that a user has had a successful in-app experience. For example when an order has been placed successfully or when an achievement has been completed. Developers can data on time spent on the app in a single session to their advantage to improve the chances of positive reviews. Asking for reviews without taking the context into consideration may also result in negative reviews. It is important to space out the review request based on usage and experience and not just on when the review request was made last.
Developer reviews
This is a much-needed feature that Apple has lagged behind on. A lot of apps may have suffered due to bad reviews for no fault of theirs. Lack of ability to contact the reviewer to understand what conditions led to a negative review has perplexed developers since a long time, since they are not able to regenerate the experience or understand the context at their end. Even with advanced analytics tools integrated in the app, it’s often not enough to determine why a certain experience failed for some users. With the ability to get more details from the reviewer, developers can now target those edge cases as well and improve the quality of the app. Developers can contact the negative reviewer and request for more details on why it didn’t work for them. What remains to be seen is whether other users in the iTunes store can also see the developer responses to the reviews.
Overall, I think the two new features will greatly help both the customers and developers in providing better support and understand the conditions of failure better. The execution is also a reflection of how Apple implements an existing feature differently.
