App Store Ratings are not the same as App Developer Ratings!
- Apr 22, 2015
- By kirthi
- In Mobile App Development
- Share on
You want to build an app of your own and market it to your existing users, and capture a new network of users. You have what you believe is the perfect idea for it, and you want to find the perfect app developer to help you bring that into place. And so, you decide to scout for one in the easiest spot: the app store, where you look for ratings to decide the choicest app developer to go with.
Stop right there.
By relying on app store ratings, you aren’t just being myopic about deciding on an appropriate app developer, but also being heavily confined by many factors that invariably render reviews near-irrelevant to your decision to go ahead with an app developer. Typically, app store reviews are a way for customers to talk about what they liked best about an app, and why it worked best for them. On the flipside, it is also an avenue to talk about what they didn’t like. To that end, it is a perfect window for people to understand what works in the market and what doesn’t, and what mistakes should be avoided.
Be that as it may, app store reviews, and their ratings, are unfortunately an implicit form of punitive measures that work the wrong way: businesses that want to develop an app, wrongly assume that the ratings and reviews are a reflection of the app developers and their work.
For starters, ratings and reviews on an app are listed regardless of the versions of the app itself. For instance, there may be a bundle of early versions that the app developer would have worked on, following which the internal team could have taken over. So what might have appeared to start off on the right track, might have appeared to have derailed in the later days owing to the internal decision to stay off the outsourcing path that might be impinging on exchequers.
A variation of this occurs where the organization changes its policies on the app’s pricing and accessibility: which tends to reflect badly on the developer.
Secondly, the ratings and reviews one may see on an app are often about the app’s promised deliverables and the extent to which they fulfilled the promises so put up. Consequently, these deliverables may not have anything to do with the coding, design or structural essence constituting it – but rather, a question of whether the user took to it as he should have. The best of interfaces that have worked for a majority always has a minority that it has not served or worked well for. This is, therefore, a yardstick for the user who buys the app – and not the one who wants to develop a whole new app. There is a clear delineation of the intended consumer of information for these ratings and reviews. For instance, games may not be supported by their device, and users may not be aware of that, or may choose to ignore that while rating or reviewing an app. A review left on a Flashlight App’s best describes this.
Let’s take a look at another example. Apple came out with an app called the 12 Days of Gifts, which worked to reward users of iOS 7, with free content and apps for 12 days. Many recipients got their gifts and accepted them, but a few did not, and wrote bad reviews and offered bad ratings to the products on offer. One of the instances where this was seen was in the case of the release of Toca House, which was a game for preschoolers. Within moments of appearing for download on the gifting app, it earned one-star ratings and bad reviews. Scratch deeper, and you’ll find that the low ratings really came from people who believed that the gifts Apple gave had to be in line with their tastes specifically. With the flak that Apple drew from this, their developers consciously decided not to repeat the scheme in the years that followed.
A third issue is that reviews cannot be relied on because they could, potentially, be fake. While the competition out there is really a challenge when there is only limited space for people to project their work, it becomes imperative that there is some amount of jostling. While some tend to play it fair and choose to operate in the bandwidth of work-based efforts, some choose to indulge in some mudslinging. This could, potentially, lead to bad ratings and reviews to falsely mislead and alter perceptions of a given app, which, when viewed wrongly or with a misinformed eye, culminates in a bad name for the developer himself.
Finally, there is the fact that developers themselves have no avenue to interface with users directly. To this end, they do not have a way to clarify to the end user that it is not a development issue, but rather one that may need legitimate support, or is legitimately caused as a consequence of factors that go beyond the ambit of a developer’s control. Users do not realise that their reviews are taken the wrong way, and even if they are informed thus, it is entirely possible that they may not be inclined to return to their reviews and change them.
To rate a developer based on the reviews and ratings on the app store for their creations, is to chop off the arm because a finger is dysfunctional. It is perfectly clear that the development of an app is a preponderant factor that encourages its existence: but the mechanisms it operates with, the spaces in which it operates, and the bandwidth of support the end product derives are not a reflection of the developer, but rather, the organization that owns and sells the app.