The (lack of) app store metrics

Apple and Google both give headline statistics of how well their respective app stores are doing, generally at their summer developer conferences. These are rounded numbers at scheduled events and they're not always comparable, but they do give us a sense of what's going on.  

Last summer, at their developer events, both Apple and Google gave numbers for the money they had paid to developers in their respective app stores: $5bn in the previous 12 months for Google Play and $10bn for the iOS App Store. Given Android has double the user base of iOS, this meant that the average iOS user was worth around 4x the average Android user in app store revenue. 

This year Apple gave the same number - $10bn (more precisely, it gave a cumulative figure of $30bn this WWDC versus $20bn last WWDC). The lack of growth may be partly due to rounding but still implies that people are spending less on average, since the user base is still growing.  Google gave no number at Google IO but it gave one earlier in the year of $7bn. It looks as through Play is growing faster than iOS and might overtake it this year (unless Apple is rounding down very aggressively - certainly the uneven shape of the graph in 2013 is due to rounding).  

Screen Shot 2015-06-13 at 11.47.31 PM.png

Since Google Android has close to double the number of users, this implies that the average user is spending perhaps half as much as the average iOS user - a change from 1/4 a year ago but still a big gap. 

Meanwhile, this was the first year since 2013 that we could compare downloads.

Google Play had 50bn app downloads in the last 12 months and iOS had 25bn, with Play appearing to be growing faster. Since, again, Play has more users, this implies roughly the same downloads per user on Android and iOS. 

Incidentally, these numbers show annualized consumer spending on apps of around $25bn, and 75bn apps downloaded in the last 12 months. 

The future is mobile and apps, except that it isn't.

There are two charts that capture a lot of the way we think about mobile today. In the first, we see that mobile devices are approaching a majority of traffic, and in the second, that a large proportion of all web traffic (a majority in the USA in this instance) and the vast majority of mobile traffic is coming from apps rather than the web. 

However, if you're not careful you can get quite the wrong impression from these. 

First, look at where people actually use their devices. 

This is a picture that you see in all the relevant data (use of cellular versus wifi data, for example) - most use of 'mobile' devices happens at home or at work, or sitting down in a coffee shop - at any rate, not just while you're walking down the street or queueing at a shop. People use their mobile devices everywhere, and mostly, that actually means when they're sitting down. The fact that the IBM data above, like much 'mobile' data, actually includes tablets, is something of a clue - people obviously use tablets sitting down. But that's true of smartphones too. 

When we talk about designing for mobile use, we tend to talk in terms of building experiences that people can see in brief moments while they glance at their phone, because they're queuing or walking or waiting for a lift or whatever. By extension, that means that 'mobile' can - no, should - be a subset of the full experience. But actually, people do do that but they also, increasingly, spend half an hour burrowing though the web or into an app, while they're sitting at home, even with a laptop in reach. So the mobile experience needs to be complete. That might, paradoxically, mean that your total experience might need to be edited, to fit, but it's dangerous to pick a subset of your offer and put just that on mobile - it might be your only touch point. Conversely, one could argue that in some cases it's the desktop experience that should be a subset of the mobile one. 

Second, about that app share of use. The great majority of app use is of course Facebook and YouTube, and in fact, app use of the internet overall is highly concentrated into a relatively small number of highly successful apps. If one looks at how people use the web on the desktop, though, you see something very similar. Most people have perhaps 10 or 20 web sites that they visit regularly in a conscious, directed way - they type the URL or click a bookmark or (most likely) search for the service name. Everything else they get to though social or search. And on mobile, most people, again, have perhaps 10 or 20 services that they use regularly - except that on a smartphone those are apps. And everything else they get to through search or social - except that social happens as a web view inside the Facebook or Twitter app and so counts as 'app use' as well. 

That is, there's a very fat head to the distribution of use on both mobile and desktop, and on mobile that goes to apps while on the desktop it generally remains within the web browser. Apps unbundle the top services into their own apps. But the dynamic for everything else has changed less - it's still on the web, mostly. As I wrote here, if people have a relationship with your service such that they'll want to put your icon on the home screen - if they'll make a conscious choice to go to you - then you should have an app as well as a website. If you're in that category then everything has changed relative to the desktop internet. But if not, then the web, search and social are still most of the story. Hence, one of the interesting trends at the moment is the attempt to bridge the web with native, non-web experiences. We see that with Google Now and Facebook Messenger (desktop sites where you place an order while signed into Facebook can send messages to you in Messenger) and with a lot of what Google is thinking with Chrome. That's not really here just yet, though. 

Mobile interaction models

The interaction model for the desktop internet was pretty much settled 15 years ago. It turned out that the answer was a web browser. Stand-alone apps such as Pointcast were a mostly blind alley, and while apps persisted for email and IM, and for very specific things like music, the words ‘web’ and ‘internet’ became effectively synonymous to anyone non-technical. Over time we added Ajax and better search and better social, but everything really happened inside the browser.

In mobile this is quite different: nothing is settled. We have the web and apps and of course app stores, and then we have many complications - voice, in-app payments, web apps, hybrid apps, widgets, push notifications, social messaging apps, Google Now and Siri. Then there’s the hardware layer - images, barcodes, NFC, bluetooth, location, motion sensors etc. Innovative and disruptive new interaction models can very often find a route to market, far more easily than they could on the desktop internet. Sometimes, they scale to a hundred million users in a year to two. And we have more and more waves of innovation coming, with things like local wireless from Apple and deep linking to within apps from Android, and a very fast-evolving social messaging space, and more things in 2014 and beyond.

So, we can actually have a pretty limited idea of what the dominant interaction models will be in 5 years. 

(There is a dream, of course, that all these nasty choices and options will go away and we can go back to the nice, simple, limited web, but that doesn’t seem very likely just yet.) 

One of the big changes here is the removal of monopolies. If the web is not the only interaction model then web search loses power as a discovery and acquisition channel. And in parallel Facebook’s desktop monopoly on social has not transferred to mobile and it seemly unlikely that it ever will (I wrote about the reasons for this here). So both of the key channels on the desktop are smaller and less crucial, and also work significantly differently, and are pretty poor at driving some key types of engagement, now that you’re not just looking for a click on a link. This changes lots of things, and creates lots of new opportunities.  

The puzzle for Google is how it brings its vast, decade-old machine learning project to bear on this new complexity of data and behaviour. The obvious problem is that data and behaviour within apps are effectively dark matter that it can’t track (hence the deep-linking initiative in Android). But this is balanced by much richer data collection. Your Android phone feeds it with data all the time - where you are, what you look at, where you go after you search and what you did the day before. The challenge is finding the right ways to collate and present that data - Google Now is one example but probably not the only one. The search box and the page of results is just one possible interface to that machine-learning project - what does Google look like after the search box?

Social faces a different set of challenges. It seems to me that on mobile Facebook will never have the near monopoly that it briefly enjoyed on the desktop - smartphones remove most of the frictional barriers that keep you on one social network. But mobile social more broadly is a vast opportunity. With web search no longer the dominant channel, social, on a far more social device than the PC, has an open door to push at. Tencent announced that the first 5 games that it launched with Wechat integration, starting in August, have had 576m registered users. Mobile social is an engagement, interaction and distribution channel, and it appears to be much richer, and probably much bigger, than social was on the desktop. 

If this is the end to near-monopolies in acquisition and discovery, it’s also interesting to think about it as the end to monocultures. If the interaction model shifts away from web search, that change makes different models and different types of behaviour possible. In turn, one might ask - what models and companies and behaviours were precluded by Google on the web? What good ideas didn’t work because of the way Google did search and the way Facebook did social? How did that monoculture shape things, and how does that change now? 

Airdrop and app discovery

Airdrop is one of the most interesting new features in iOS7. It takes a new P2P wireless stack built in at a lower level, and offers it as part of the standard system sharing panel. 

Apple demoed it using photos, but since it's a system service, any app can use it to send, well, anything. Kayak is using it to share flight searches - click on the images to see the user flow. 

This is zero configuration and needs no access point or cellular coverage - it just finds who's in the room. 

A preview of some kind might be better in the last call to action (Kayak is using a URL scheme). But apply a little imagination, and you can see all SORTS of things you could use this for. Anything you can turn into a file or link can be handed to a friend as you chat to them. Magazine articles, property or restaurant listings, game levels, in-game currency...

Of course, featurephones had this a decade ago with Bluetooth, theoretically (and this uses Bluetooth for some of the process). But Airdrop uses nice fast wifi for transfer and, as so often, Apple has taken an existing concept and 'productised' it - turned it into something normal people might use without any trouble or fuss. 

App stores, portals and discovery

We used to browse Yahoo to discover cool websites. 15 years later we browsed apps stores in the same way. Neither scaled very well. 

For those too young to remember, Yahoo started as a hierarchical tree that, theoretically, contained every single website that existed. The screenshot below (from the Web Archive) shows it circa 1996. If you clicked on those links you could see a listing for every site on the web (or at least that was the idea). Does this look familiar


Screen Shot 2013-08-15 at 11.10.36.png

Of course, this didn't scale once the web started taking off. You can't browse through a catalogue with millions of entries. Equally, with over 900k apps on the iOS app store and almost as many on Google Play, browsing there has also become meaningless. Browsing an app store is like browsing Amazon - you could spend the rest of the year clicking 'next item' and not see that one cool thing you really want but didn't know existed. 

After the web directory the next stage was the 'portal' - a page with someone's ideas of what might be useful. This is what Yahoo became, and it's also what the front page of the iOS or Android app stores look like now. The purpose of these screens is not to allow people to discover your  app or service - they cannot hope to be comprehensive in that way. The front pages of an app store do not exist to help developers - they can't. Rather, they exist to help the users - to ease them into the idea of apps. But they can only scratch the surface of 'discovery'. 

All of this means that saying "we made an app and no-one downloaded it, and Apple didn't help" is like saying "we made a website and no-one came, and Google didn't help" or, even more, "I wrote a book and no-one bought it, and Amazon didn't help". Amazon might help - it might feature you, just as Apple might. But that's for the users' benefit, not yours, and it cannot possibly scale to all apps or all books. 

The difference between Yahoo and app stores, of course, is that web search came along and addressed some of the underlying tasks in a quite different way, but search does not necessarily work well for apps. Search requires you to know roughly what you're looking for, but a lot of the best apps (and indeed web sites) are things you hadn't imagined could be possible - they're 'magic wands'. If you didn't know Hailo or Evernote were possible you wouldn't search for them - and yet the app store home page cannot possibly showcase all such things. 

The obvious answer, of course, is self-promotion - you promote your app like you would your website or your book.

Screen Shot 2013-08-15 at 11.54.14.png

But there are some other more interesting things also going on in discovery.  

The first trend is the way that Siri and Google Now surface information. If you ask Siri for sports scores or restaurants or films, you don't need to work out what the best service or app to use might be - you just ask the question (and Apple's BD team has picked one). Google Now takes this a step further - it it also knows the sports score, but it tries to work out new things you might be interested in unprompted - it reads your email, knows you're interested in a flight and pops up to tell you it's running late. As they develop, these concepts may work well for the discovery of some kinds of apps, but neither approach scales well across thousands of apps. And neither would tell you about a 'magic wand'.

The other trend, though, is social. I don't really mean social recommendation aggregators, which work on the basis "people who liked this also liked'. Rather, plain vanilla sharing. Twitter cards let you share an app directly, but also deep link to content within one. 


Many of the emerging mobile social messaging apps are trying to turn themselves into platforms, and they have hundreds of millions of users. A little piece of atomised content, a card, the size of a smartphone screen, embedded into a message, is a great way for knowledge of a service to spread (I wrote a little more about this angle here). Meanwhile,  the grandpa of social networks, Facebook, is pushing hard to build a mobile app distribution business. Kik, of course, has just launched a Zynga game built in HTML5 within the messaging app itself. 

Even more interesting, though, are some of the APIs inside iOS7. Apple has built a local, zero-configuration wireless sharing tool kit. No access point and no NFC needed - any app can reach out and find any other iOS device.

Screen Shot 2013-08-15 at 11.45.52.png

Apple surfaces this in the new system service Airdrop, shown above. The demo uses photos, but Airdrop is part of the standard sharing panel that any app can use, and (without breaking the NDA) it looks like anything you can make into a file could be sent. So an app can include a 'share this with friends' that sends people in the room an app store link. Or a game level. Or in-game currency. Or a deep-link to content within an app. That makes app discovery work quite differently. 

Airdrop, though, only works with people in the same room, and so has a different set of scaling problems.  The leading social messaging apps all have hundreds of millions of users, and I've lost count of how many such services there are in total - I found over 50 on Google Play that had over 1m reported downloads, and there are dozens more. Pretty soon there'll be more messaging apps than ad-tech companies - a new bubble is inflating. But  there might be a fair bit of value for those that can turn themselves into distribution and discovery channels. 

Twitter, canvases and cards

Twitter used to be a protocol - rather like SMTP or IMAP. Other people made Twitter clients, with many different interfaces, and Twitter poked around with metadata (adding retweets, for example), but the user experience was something other people built.

Then Twitter pivoted, and deprecated the third party apps, and took control of the interface. The obvious thing that it did with that was to deliver a predictable offer for advertisers. But the more interesting thing to me was that it created a canvas - which is now turning Twitter from a protocol to a platform. 

Twitter is turning 'Twitter cards' into a platform. You can embed video, or slides, or music - all sorts of things. You can embed a call to action that will harvest the account's email address. And, increasingly, you can drive acquisition - of Spotify users, or apps, or customers. And thanks to retweets these cards can end up anywhere on Twitter, far beyond the original poster's network. 


Twitter isn't the only company doing this sort of thing. Many of the new crop of social messaging apps, such as Line, Kakao, WeChat and Kik, are also creating canvases of various kinds within their services - within individual messages. Kik and WeChat are exploring HTML5 games within the app itself, and WeChat is playing with retail coupons. Some of the results are pretty strained, but there's obvious value in being able to send tracks, game levels or yelp reviews through such apps, and sending them as rich, actionable cards is much better than a URL string.

(Interestingly, though, probably the biggest social messaging app outside China, Whatsapp, is pretty much the only such app that isn't  trying to become a platform in this way, at least not yet.)

Cards are an interaction model that are spreading pretty widely, in fact. They're an important part of how Google presents the newish 'entity' based search, which crop up in the right sidebar on the web and of course as part of Google Now. Part of the magic is the semantic understanding of data that lets Google make these automatically, but the presentation is, again, a card. 


And then there's Airdrop, an intriguing feature in the new iOS7 that's been rather buried by all the fuss about the new visual design. Instant, zero-configuration local sharing (remember Bluetooth?). Apple's screenshots focus on photos, but to developers this is just part of the standard sharing API, and you can put anything in here - coupons, game levels, deep links to reviews or songs. But instead of sending it by SMS or email, you can pass it across a bar top. No canvas, this time (except for pictures themselves), but again the atomised content. 


What all of these have in common is that they're pulling information out of the app or the service and making it relevant to the moment. They're taking things out of silos, packetising them and making them sharable. But at the same time, they're making them canvases - not just files, but cards, content, real things that you can pass around. 

In some senses, this started with Facebook, which had a canvas a long time ago (in internet time, at least). Facebook is present on mobile and doing well, claiming close to 800m mobile users, though it isn't close to winning in the sense that it won on the desktop, not with hundreds of millions of Facebook users choosing also to use WhatsApp et al.

But Facebook is about aggregation - about sucking everything into the gravitational well and spitting it back out through a black box filter to stop you being swamped. Facebook is an endless stream whereas cards are individual. The point of 'cards', like the story of mobile social, is disaggregation - of the over 200m people who already had Facebook but are using WhatsApp for messages - the 100m Instagram users who prefer it to Facebook for photos, and so on, and so on.  

From a business point of view, this is interesting because it points to distribution and discovery. How do new products and services get passed around? How does social sharing evolve? Complexity is increased, too - how do you do SEO for Google Now? How should you think about conversion rates on a Kik card or a game shared over Airdrop? There's a sort of inexorability to this: Zawinski's Law states that "Every program attempts to expand until it can read mail." One might now say that every product and service online expands until it can distribute freemium games. 

I think there's also a question of being native to the platform, though. Chris Dixon wrote recently about finding things that are native to mobile as opposed to mobile versions of desktop products. What could be more native to a smartphone than a piece of content the size and shape of a smartphone screen, that can be sent anywhere?

How many apps do Android and iOS users download?

Both Apple and Google give occasional numbers for cumulative downloads of apps on their respective smartphone platforms. These are generally round numbers and they're often given at scheduled events (quarterly results, developer conferences), so we don't know how precise they are (did it pass 25bn yesterday, last week or last month?), but they're still useful. I've plotted the data sets in the scatter chart below: the wobbles in the lines are probably more to do with this precision issue than actual user behaviour. 

Screen Shot 2013-05-16 at 12.52.11 PM.png

Android started later and is catching up in cumulative terms. Both are now at or around 50bn: Apple announced 50bn on 15 May and Google announced 48bn on the same day at Google IO. 

What does this look like on a monthly basis? It's possible to build a model that interpolates the run between the data points we're given to work out what the monthly run rate would have to have been. This isn't perfect, but it's all we have. The chart below shows my model's output for Google Play laid over the data from Google itself, to illustrate the process; I've done the same for Apple. 

Screen Shot 2013-05-16 at 12.57.58 PM.png

Working this through, we can infer:

  • Android app downloads on Google Play in Q1 2013 were about 9.75bn
  • iOS app downloads were about 5bn (conveniently, Apple stated 40bn in December and 45bn in March, which makes the maths easy even for a history graduate like me). 

How does that relate to users, though? 

If we take trailing 24m unit sales as reported by Apple, the iOS base was 400m at March 2013 and 370m in December, giving an average for the quarter of 385m. Hence there were an average of 13 app downloads per live iOS device in the March 2013 quarter. 

Android is a bit trickier, for two reasons. First, to get to an active base we again have to rely on interpolating cumulative numbers, in this case Android activations, with the same precision problem. Doing this, and taking the same trailing 24m sales, my model says there were 590m live Android devices at the end of 2012 and 680m at the end of March, an average of 635m. This implies an average of 15 downloads per live device in the quarter. Given the degree of imprecision in the model, this is probably close enough to be the same. 

Just to repeat - the data is not exact enough for these to be more than reasonable approximations. It's quite possible that Apple is at 15 and Android at 10, or the other way around. 

But then there's the second problem: Google's data, both for activations and downloads, does not actually give the fully picture for Android:

  • There are many third-party Android app stores, including Amazon's, for which we have no data, and piracy also appears to be more widespread on Android
  • Android in China is largely absent from both activations and installs, since most Android in China is sold without any Google services and so never appears in Google's statistics

Finally, of course, we have no hard data at all for Google Play revenue. Apple gives cumulative revenue on the same basis. This allows me to estimate that gross revenue on the app store (i.e. including Apple's commission) is running at about $1 a month per live device, and has been stable for at least a year. Google is not so forthcoming. 

Finally, these numbers are accelerating. Apple did 5bn downloads in the three months from December 2012 to March 2013, and then another 5bn from March to 15 May. The lack of precision means we can't say this was double the rate, but the trend is clear, and it looks the same at Android, which announced 'over 2.5bn downloads' in the last month' For all the talk of HTML5, apps are as popular as ever. 

Note: both Apple and Google derive these numbers properly. Updates, re-downloads and downloads to a second device are not included. It's one download per user account per app. Matthew Panzarino at The Next Web went and asked

GetJAR, Facebook and failed downloads?

GetJAR reports that it has delivered 113m downloads of Facebook mobile apps. This covers Android, Nokia and the J2ME feature phones but not (obviously) iOS, nor preloads of OEM Android apps, which are huge. 

But according to Facebook those three addressable categories ‘only’ add up to around 66m active users. And GetJAR is competing with the Android Market for installs, so there should be even more than 113m Facebook downloads to reconcile with those 66m actives. 

There are two three possible explanations:

  1. a massive failure rate for installs of downloads: 50% or more (i.e.people download the app but then can’t find it or make it work)
  2. a massive featurephone base not showing up in Facebook’s app-by-app stats. However, there isn’t really room in the numbers for this latter: as the charts in my previous post show, iOS, Android and RIM apps account for 210m of the solid 250m mobile users number that Facebook discloses
  3. GetJAR is including application updates in downloads