The "app gap" isn't what you think it is

It's easy to think of the app gap as "Platform X has more apps than Platform Y". It's much more subtle than that...
Written by Matt Baxter-Reynolds, Contributor
App Gap

We know that Windows Phone is often held up as having problems with the "app gap" -- a situation which describes a user being unable to get the apps that they want on their device.

But there's much more to this than just "Platform X has more apps than Platform Y." Windows Phone has most of the "popular" apps at this point, yet the perceived problem still persists.


One thing to accept with the app gap is that it will always exist.

For the sake of argument, you can assume that the effort required to target each platform is roughly the same. This is a slightly dangerous position to hold, as anyone who is smitten with their platform of choice will argue against it. For me, the rules of the universe in general are true here -- you don't get something from nothing, and you cannot magic an app out of the ether.

What this means is that if you have three platforms in a market, the one in last place will always be unloved. By definition, the lowest share must be 33 percent if you assume 33.5 percent each for the other two. If you assume that your development effort per platform is "x", then a "2x" expenditure will net you minimum coverage of 67 percent.

In reality, the Rule of Three tells us that market share for the top three placed generalists (Android, iOS, and Windows Phone) hover around 40 percent, 20 percent, and 10 percent respectively. It'll be slightly different in the smartphone market -- the Rule of Three leaves a lot of space in the market for specialised players, and the ecomonics of making smartphones is unfriendly to specialised.

So then, let's assume the third place player gets 20 percent, the other two get 40 percent and 35 percent, and specialists (BlackBerry? Blackphone?) get 5 percent.

That means now you have your "2x" cost netting 75 percent of the market. Moreover, the economics stop scaling. A "3x" cost only gets you an additional 20 percent. Most developers will demure from taking that "2x" investment up to "3x" unless there is a very compelling commercial argument to do so.

Looking at app store numbers to gauge the app gap is essentially useless. The economics of how software is made gives a much better answer -- the third place player, whatever that is at any point in time, will always lag.


An assumption that we'll make here is that users do care about apps. While there are some situations today where that is not true -- think Android users who don't buy data service for their phones -- that situation will change. Over time, apps that run on mobile devices will take over from the generalised web. It'll be through mobile apps that most people perceive the internet.

My view is that you can categorise apps into the following simple groups: games, the "burger joint" app, and service access.

For "games", you have to look at the experience. If you're really into mobile gaming, you are likely to look at volume. You'll play a game for a while, get bored, and seek another. Thus in this category, the app gap is important as you want the highest throughput of possible games.

(Remember as well that the app stores have historically been very top heavy with games --  of the top 100 apps, typically around 80 percent on iOS have been games, and 70 percent on Android.)

The "burger joint" app model is how I collate together apps that are designed to enhance brand loyalty and brand experience. Think about a poster outside a burger joint with "Available on the App Store" and "Get it on Google Play" messages. You see the advertisement, download the app, and get (say) free fries on that action.

These are the sorts of apps that are most sensitive to the "2x vs 3x" investment metric mentioned earlier. The management of the business is not using these apps as a revenue stream -- they are part of a sales and marketing budget. They will need convincing to broaden out and hit all three platforms.

This is unlikely to affect platform adoption though. If you have a device that's not supported on the scheme, you'll just opt out of the marketing. No one chooses an expensive smartphone just to get a free burger every couple of months.

The most important type of app is the "service access" app. This describes an app that only exists to get you into some other service, such as Facebook, Twitter, eBay, Instagram, etc.

Fortunately for everyone involved, users move onto and off of these services very slowly. In order to start using a service, you have to make increasing levels of investment. Firstly, you have to be convinced to use it. (If you're a Twitter fan, try convincing a non-user to love it as much as you do.) Then you have to use it enough to get value out of it. At some point in the future, some event will likely convince you to stop using it.

This curve takes a long time to get through -- often it can take multiple years. That means that any given user will have "service adoption curves" for different services that overlap at different points. This lessens the effect of the app gap, because it's only apps+services that the user has reached the peak of their investment in that they will care about.

To put it another way, that user is not going to see the value in services that they haven't used yet because value is experiential. No Instagram client on Platform Y? If you've never heard of Instagram, that's going to have zero impact on your decision.

For the user, they're only going to care about platforms they've already made an investment in when they come to choose a smartphone platform. Nothing else will really count.


When you're thinking about the app gap, just remember two things. One: there will always be an app gap. The economics of software development dictate that it must exist. Two: the relationship with the underlying service is the important part.

This is why all the platform owners like the virtuous circle of "devices plus services".

What do you think? Post a comment, or talk to me on Twitter: @mbrit.

Editorial standards