App Store Ratings needs some modernisation


This has been somewhat of a pet peeve of mine, the fact that Google Play and Apple Store app rankings are based purely on app downloads as well as user feedback (stars, comments) in order to reward and provide for greater recognition. Since the start of both app stores, the structure hasn’t dramatically changed, albeit we have seen some minor changes, including algorithm changes to reduce fraudulent rankings.

App Store rankings traditionally rely on two factors, (1) number of app downloads and (2) rate at which that app is downloaded, which ascertains to obtaining a ranking.

Whilst I am not adverse to the notion of ranking based on downloads and rate or trend of downloads, there are two additional factors I believe would aid in creating a more accurate representation of app popularity, that Apple would need to implement on a platform-level.  

Usage duration/tracking

If Apple would be able to track not just how popular an app is via download rates, but to track how often an app is used, daily, we would be able to determine that an app maintains it’s usefulness beyond the initial download stage. 

An app that was not just downloaded during a popular marketing period, but gains more usefulness later on whilst on the user’s device, being relied on daily should factor in recognising that an app is not just sitting dormant on a user’s device or downloaded and deleted, but actively used.

Exit survey & Rating API Access

I’ve always had an issue with how users rate and star apps. Usually if you are doing a good job, you won’t have many people going out of their way to go to your app listing and give you four or five stars and a comment, unless you really touched them .

Most times, if a user has had a really negative experience with your app they will go out of their way to make themselves heard. Now, this isn’t a hard fact of mine, as we do see a lot of people that give good ratings, I just believe proportionally more negative experiences get a rating than positive ones. 

Encouraging users to post positive ratings and comments has been a challenge over the years and the general best-practice is to prompt the user to rate at an opportune time. When a user has completed a task, during that short time of gratification, the user would most likely be in the midst of a positive experience, in which case the user would feel compelled to give you a positive review. Prompt the user too often or indiscriminately and that may not be the case.

What I would like to see in 2015 is for Apple to adjust this so that you have direct access through the API to provide a system RatingViewController, so you can add stars within the app and not have to exit the app. This adds for better usability.

Secondly, when a user delete’s an app, the system should also provide an exit survey opportunity, an ability to provide a star and comment to let developers know that there is a problem with his or her experiences, in what is called an exit survey. This may not necessarily yield a positive review, in fact you will probably get a negative review, but hopefully, it would be a more constructive comment. 

These are some thoughts I have regarding the App Store, that Apple needs to look at.


Twitter is in the big leagues, as far as APIs are concerned, and its gotten its second wind with Fabric Suite, announced at the Flight Developer’s conference earlier this year. This year Twitter also ramped up its login mechanism, as part of Fabric Suite, which bore the fruit from last year’s acquisition of Crashlytics


Crashlytics, acquired in 2013, forms the bulk of the Fabric suite. Crashlytics’ crash-reporting framework is all at once simple and sophisticated, monitoring app releases on iOS as well as a few other utilities that integrate well with that particular tool. Beta Distribution provides a yet-another convenient distribution tool for testers, while the Answers tool tracks distribution, crashes and general use for greater app insight. Twitter plans to add to the suite of utilities, although the company has not released much in the way of a roadmap.

The final piece in Twitter’s 2014 push to match Facebook’s mobile initiatives is TwitterKit, which provides a revamped sign-in API that is much simpler to implement, as well as an easier hook to access associated feeds and followers. Digits is Twitter’s answer to Facebook’s Anonymous login project, but with a creative twist: It allows users to maintain their anonymity, by signing up as well as signing on, using their phone numbers. You don’t need to provide your email address or Twitter credentials to login; this allows developers to provide a more digestible barrier to accessing an app. Anonymous users can be linked to Twitter accounts at a later stage, when users would presumably be more comfortable with “opening up.” In the new year we will be looking for tweaks to TwitterKit, as well as some significant documentation (currently absent) early next year. API-wise, we expect to see some of the more complicated SDK methods gradually making their way into TwitterKit, with a more straightforward implementation.

To read my entire article, go to;

Mobile APIs That Rocked In 2014: GOOGLE MAPS, FIT, ANDROID & YOUTUBE

Google has continued to iterate its popular APIs–including those for YouTube, Google Maps and Google+–for both the Web and android. The various API webpages now include blogs and user stories. On the Android front, Google has introduced Google Material Design, the company’s ambitious attempt to provide a language that will serve as its advocacy platform for best-practices UX design.


In October Google introduced an open-source reference implementation of YouTube WatchMe for Android, which brings an easy-to-implement version of live broadcasting for Android mobile devices. The SDK exposes an implementation that already existed in various Android handsets, such as Live on YouTube – by Xperia and Re – by HTC. This open-source project allows developers to provide streaming capabilities in mobile apps, which could provide for some interesting business use cases. YouTube’s API is Google’s most popular SDK, and we expect to see the next version in 2015, including better integration with Google’s central API infrastructure. The library is expected to get even more efficient, and we will look for better perofrmance increases next year (after a positive performance boost this year with JSON encoding over XML encoding)

Google Maps

Google maps on ChromebookGoogle maps on Chromebook

Google maps on Chromebook

Google has finally deprecated Google Earth, a project that spanned more than six years. On the SDK front, Google has been ramping up usability features, such as localizing street addresses in Google Maps and adding street view to maps embedded in HTML. Google Maps for Android API has also been improved, with the addition of a toolbar that gives users a jump-start to gettting directions and turn-by-turn navigation. There’s also a “light” mode that provides a minimalist, non-interactable bitmap iamge of a map at a specified zoom level and location. The Google Maps Android API has been ramped up with a new asynchronous method that notifies the developer via delegate when a map is ready to be consumed, as a replacement for the deprecated getMap() method. With all that said, Google Maps is quite mature, so the changes we expect to see moving forward are incremental, with minor changes in line with the Google Material Design principles and adjustments to support Google Maps for Android API.

To read my entire article, go to