Messaging and mobile platforms


One of the fundamental things that smartphones changed about the internet is that the smartphone itself is a social platform:

  • Every app can access your address book, getting an instant social graph. The phone number in particular acts as a unique social identifier
  • They can access the photo library and camera directly (and location), making sharing easy 
  • Push notifications mean you don’t need people to keep checking your site (or open emails).  
  • Every app is just two taps away on the home screen, which makes switching services easier, and also drives a trend for focused, single-purpose apps over apps that do everything - it's easier to find a feature as an icon on your home screen than as an option in a sub-menu of the Facebook app

So joining a new service from a different company is much easier than it was on the desktop and, crucially, using more than one at a time is also much easier. People can swap apps in and out for different behaviours or content types or social groups, on top of that underlying platform, and they do it all the time. And so there has been an explosion of apps trying to take advantage of this. Facebook bought two of the biggest, Instagram and WhatsApp, but it can't buy them all. 

Looking at all of these apps, I think there are three threads that we can pull out:

  • More or less plain vanilla person-to-person text messaging, with extras like group chat, pictures, stickers and voice clips etc added on. The big global winner so far has clearly been WhatsApp, which dominates outside the USA and East Asia (and is doing 50% more message volume than the entire global SMS system), but Facebook Messenger is doing pretty well too, mostly in the USA. I'd expect relatively little new innovation to happen here now, and most of it to be in the next two categories:
  • New pieces of psychology - new behaviors or attitudes that an app can enable or ride on. Sitting on that underlying social platform, an app that finds one of these can go viral. Examples include Instagram, Snapchat, Yo, Yik Yak, Secret or Meerkat. The challenge for these is to find a behavior that's different and compelling enough to create that growth, but not weird or specific enough to be a gimmick or a fad and flame out, or at least to evolve beyond that specificity once the growth is there, which one could argue Snapchat is doing
  • Platforms - messaging apps that aim to broaden the UX beyond pure person-to-person messaging into a development environment. WeChat is the big example here, with 500m users, almost all in China, while Line in Japan and Kik in the USA are also significant. 

The potential to turn messaging into a platform is the Trojan Horse that drives a lot of the excitement in the sector. It's one thing to sell stickers and quite another to sell users: can you use social to spread content and acquire users, and to solve the problem of app installation? Can it become the third runtime and the third channel on the phone, after the web and native apps?

The first big success here has been WeChat, which has 500m MAUs, almost all in China. WeChat has built a messaging client that's also a development environment, using web views and APIs so you can build services within the app that can access location, identity, payment and other tools from within the app. You can send money, order a cab, book a restaurant or track and manage an ecommerce order, all within one social app. So, like the web, you don't need to install new apps to access these services, but, unlike the web, they can also use push and messaging and social to spread. This is Facebook's old desktop platform, more or less, but on mobile. 

The common criticism of this approach is that this is 'just a portal', and that integrating lots of different services into one app is doomed in the same way that Yahoo on the desktop was doomed to be replaced by more powerful and focused single-purpose products. The more subtle version of this is that WeChat only works in China because the market structure is different - no vertical category killers (Google, Facebook, Amazon) and instead parallel, horizontal competition by large competing companies. WeChat is providing the 'primitives' that you can't get elsewhere. This may be true - but it may also be that WeChat (and similar products such as Baidu Maps, which also has deep service integration) show us what the rest of the world might look like if the big portals had executed better. That is, is this what Yahoo would have achieved if it hadn't gone to sleep for a decade? *

A lot of people thought that Facebook would clone this, but it's actually done something quite different. Rathe than trying to turn Messenger itself into a development environment, it's opened it up to become a channel for anything else on your phone and the web. This means that it's addressing both the platform thread and the viral apps thread outlined above, and that rather than WeChat, it's going after the iOS and Android notifications panel. 

First, if you have an idea for a great type of content for messaging - a new piece of psychology that might go viral - your iPhone or Android app can now insert that directly into a thread inside the Messenger app, and your app can be invoked directly from within the Messenger app. Messenger has a list of featured apps (with links out to the App Store or Google Play) and, crucially, each piece of content posted into a message thread comes with a link to install the app - a viral hook. Facebook has made an API for the 'sticker button', and turned it into an acquisition channel for third party apps, and is now letting the entire internet compete for that slot, with itself as gatekeeper.

 The WeChat model achieves some of this, avoiding the app installation problem itself by putting everything into web views within the WeChat app, but that puts a cap on how sophisticated you can get - it's hard to make video clips with web apps. Facebook is trying to square the circle - rich native code to make cool stuff, yet no need for an app installation for it to spread. 

This is a great jujitsu move, and very seductive. Facebook is trying to co-opt the next Snapchat. Yes, the smartphone is a social platform that makes it easy to use multiple social apps, but you still have to get someone over the hurdle of installing the app in the first place, and they have to get all of their friends to install it too so that they have someone to send to.  Facebook is trying to bypass that - you can drop your content straight into the existing Messenger install base (600m MAUs). Now just one person can get a cool app and send messages to their friends even if their friends don't have it, and if it's cool enough they can tap on the link and install it too.

So acquisition is much easier, but they're Facebook's users, and always will be. And since there will be dozens of apps fighting it out for that slot, Snapchat and any other new stand-alone network will be competing against all of those apps - against the whole app store. This means that Facebook is trying to reset some of the dynamics I described at that beginning of this piece - it's trying to avoid the 'whack-a-mole' problem of having to buy cool new messaging companies (Instagram, WhatsApp) by getting those communication forms to happen inside Messenger instead, using Facebook's own social graph instead of the phone's address book.  And as I said, this is seductive - Facebook removes a major barrier to growth, but owns your users and has a history of ruthlessness in dealing partners who build on its platforms. Join, get growth 'easily' and give Facebook control, or stay out and struggle for installs against Facebook and all its partners as well. 

The second part of the Messenger announcement is just as interesting - Facebook will also let websites send messages directly into Messenger, without having their own apps installed on your phone, if you logged into that website with Facebook when you placed the order. So you can order shoes and get a message in Messenger that they're out of stock and be offered an alternative. This is another attack on email (and Gmail) and another attempt to pull your communications and commerce into the Facebook data platform. And again, if you do this you get richer and more engaging communication with your users, and don't need them to install your app, but your access is entirely controlled by Facebook.  

If you take all of this together, it look like Facebook is trying not to compete with other messaging apps but to relocate itself within the landscape of both messaging and the broader smartphone interaction model. Facebook Home tried to take over the home screen and lock screen - Messenger is trying to take over the notifications panel, by pulling those notifications inside its own app, and to co-opt large chunks of future communications developments on the phone.  

This make perfect sense - notifications themselves are becoming that third runtime. That pull-down panel aggregates activity from everything on your phone, and Google and Apple have made notifications actionable and given them payloads. One can already look at an iPhone or Android phone's notification screen and ask - 'where's the algorithm filtering this?' And in a sense, the notification panel fills the 'cross platform compatibility' role that some people would like to see in messaging - all the notifications for all my messaging apps show up there. More and more, one's primary interaction with any app, social messaging or otherwise, is a little pop-up with a button or two. So shouldn't that get a native, messaging-focused UI? Instead of replacing stand-alone apps with light-weight versions built inside a messaging app, is it better for rich, actionable messages from native apps to be aggregated into a notification panel? Once you have that runtime, do you need an actual stand-alone app on the actual phone itself, or can you send those messages - really, little applets, down from the cloud? Do you turn apps into messages and notifications, or messages and notifications into apps?

Meanwhile, smart watches (to the extent that they take off) reinforce a model of atomic units of content with a handful of possible actions, and of glancing at a few key items rather than submerging yourself in a dedicated UI. So after unbundling sites from the web browser into apps, notifications take things further, unbundling each unit of content or action - each verb or noun - into a separate atom. So you can order a car with a flick of your wrist and a tap or two, instead of fishing your phone out of your pocket, unlocking it, loading an app and navigating the UI. 

This obviously leads one to ask what the platform owners themselves are doing. Should this be done by Facebook or the platform owners (the same question as for deep linking last year)? Do Apple or Google introduce an algorithmic filter to manage the flow in the system-wide notification panel, and does that compare to Facebook's lethal power over newsfeed partners? They're some of the way there. Both Apple and Google have perfectly solid mobile messaging apps that are not development platforms in their own right, and have done a lot of work on notifications in their smartphone OSs yet clearly have lots more to do. And Apple already lets websites send push notifications on OS X, while Google is clearly pushing Chrome hard as a development environment and so notifications from the web there would also make sense. 

So we can see some building blocks, but we can also see obstacles. The obvious one is that neither has the kind of desktop social presence that would make it easy for them to drive personalized push motivations for web to mobile - you're not logged into anything from Apple or Google (pace Plus) when you shop on the desktop web. On the other hand, you're always logged in on Android, and Apple has shown plenty of hints that it might see TouchID as a universal identity platform, and of course, they do have your address book. So Apple or Google could easily let an app send a push notification to a friend who doesn't have that app. Meanwhile as mobile devices zoom past half of time spent on commerce sites and a third of the transaction value, a web identity platform might matter less. There are other interesting possibilities too, if one thinks where Now or Passbook might fit into this. 

The core issue across all of this, I think, is how much is still totally unsettled. We spent 20 years in which the mainstream internet experience was a web browser, mouse and keyboard, and over a decade in with Google was the way you navigated. Smartphones ended all that but we haven't settled on a new model, and the idea we'll all revert back to the comfortable, simple model of the web seems increasingly remote. Even within messaging, the  model is still in flux. I wrote above about the search for new psychologies, but there are deeper architectural questions than anonymity or filters, which you can see in SnapChat's disappearing messages or Meerkat and Periscope's use of live. What will the next blow-up model be -  synchronous or not? One to one or one to many? Feed based or thread-based? Algorithmic filter or endless stream? Rich client or rich message? Runtime or deep links? That may be the real problem for Facebook - the next messaging thing may not be messaging at all. 


* As an aside, it's challenging for anyone outside China to have a firm view on WeChat given that almost no-one has actually used it - the most interesting features only appear if you run the app with Chinese language settings. I don’t read Chinese myself, and I’m always reluctant to have a strong view on a product I’ve not used, though this is a minority position.

App store revenue, and selling to the world.

Last summer, at their developer events, Apple and Google told us that the previous 12m months, Apple paid $10bn to developers and Google $5bn. Now we learn that Google's up to a $7bn run-rate. In December, Apple repeated the number - that might mean flat growth, or (I think more likely) that they were just repeating the same number. We don't (yet) know where Apple's grown to since then (hint, hint). 

If we gross up this new Google number and the most recent Apple number, incidentally, we get to close to $25bn in annual consumer spending on apps.

Google also told us last summer that it had 'over 1bn' users of its version of Android (i.e. not counting China, with China also not counted in the revenue numbers). Since at that time my model (and others) estimated that Apple had about 625-650m live iOS devices, that meant that the average iOS device was generating 3x to 4x more app store revenue than the average Android device ($10bn and 625m users versus $5bn and 1bn). We cannot tell from these numbers if that's changed since then. On one hand, Google has improved monetisation, but on the other, all the new users since then will be on lower incomes with lower propensity to spend, and we know neither the Android user base nor the iOS revenue. 

The other point that Sundar makes is that Android is selling a massive range of devices to a massive range of different people, whereas iOS is selling to people who can buy $600 phones. This is true, and it's inherent in the different models, and both are great models. This is why I've said that both Apple and Google have both won the platform wars, for now. Google got reach and Apple got device profits (which Google doesn't care about) and an ecosystem with sustainable scale. These numbers make it abundantly clear why iOS is not going to lose access to the best apps. But it's also why Android ARPU is lower (and of course this difference is seen in ecommerce spending and traffic as well, not just spending on apps). If you sell to everyone, well, the average user is going to be different to the average of people who buy $600 devices. Again, that's fine, and it's inherent in the model. 

One final observation, too: both Google and Apple have smartphone platforms and ecosystems with massive global scale and stable, sustainable dynamics (though the dynamics of the Android OEM space may be another question). That means that working out the horse race between the two is now pretty irrelevant. Again, they both won, so what's next

App unbundling, search and discovery

"There’s only two ways I know of to make money: bundling and unbundling."

-Jim Barksdale

There’s been a pretty clear story for the past couple of years that the dynamics of smartphone interfaces drive unbundling of services. 

The main reason is that single-purpose applications have an advantage on smartphone interfaces. On a desktop website, you could always add a feature as a new tab on your site navigation, and clicking that was easier than going to another web site. But on mobile, all apps are just two taps away, while there is very little room for links to more features in any given app’s home screen - they quickly get shoved into the ‘hamburger’ menu, and soon after fall into the ‘hamburger basement’, down below the bottom of the screen. This gives startups scope to unbundle features from larger companies' products, and also means those companies themselves unbundle their apps into separate single-function apps. 

This effect is even stronger for social applications, where a lot of the unbundling conversation focuses, since the smartphone is itself a social platform quite unlike a desktop web browser. All apps can access the address book, giving them a ready-made social graph, and the photo library, reducing the hassle of uploading to different sites, and push notifications, removing the hassle of checking lots of different sites. This is why we have dozens of social apps that have passed the 1m, 10m or even 100m user milestone. 

Finally, of course, driven by all of these dynamics, all smartphone apps by their nature unbundle services from the web browser itself, 20 year after Netscape launched. 

All of this seems inevitable and inherent in the nature of the platform. It’s the reason why Facebook has moved from a de facto monopoly of social on the desktop to being merely the leader on mobile, buying the occasional breakout unbundler while experimenting with its own suite (‘constellation’) of different apps searching for new use cases

However, looking at the Chinese internet market is always a great way to challenge your belief in what’s inevitable, and in this case both Baidu Maps and WeChat, amongst others, are thriving on exactly the opposite approach - bundling multiple services into one app. (WeChat and Baidu Maps are a bit different, so I'll focus on Baidu)

Hence, in Baidu Maps you can not just find a restaurant but book a table or order home-delivery. You can find where a film is showing and choose a seat. You can order a cab, with cabs from all the services in your city shown together on the map and the order going to be best offer. You can book a hotel room or a cleaner. Most of of these services are provided through embedded third-parties - Baidu is doing deals with other Chinese internet companies to provide this. WeChat (which now has close to 400m MAUs), is doing much the same, but of course starting from a chat experience rather than a maps experience.

In both cases, the aggregations make a fair amount of sense on their own terms - finding a cinema, taxi or restaurant are location-based activities and they’re also social activities. But the functionality is being flipped upside-down: in the USA a taxi app or a restaurant app will have an embedded map, but in China the map has embedded restaurants and taxis - and lots of other things. Equally, on Yelp you can message friends, but in WeChat you’re already in the messaging app. 

This changes the layer of aggregation. By default, the iOS and Android interfaces aggregate at the app launcher level - you have a screen of different icons for different services, though to some extent notifications are becoming another OS-level aggregation. Anything that hasn't been unbundled from the web is in the browser, where it is in turn aggregated by Google. Apps like WeChat and Baidu Maps move the service aggregation layer up the stack from the home screen, bundling it within a single app. Conversely Siri and Google Now (and arguably Microsoft's Live tiles) are in different ways about moving it down the stack into an OS-level service. But the interesting thing is that changing the aggregation model also enables new types of discovery.

In the app launcher layer, any direct service discovery (as opposed to marketing, word of mouth etc) is limited to the app stores. When they launched this worked adequately, but with over 1m apps in each of the iOS and Android app stores this model is clearly now broken. Just as Yahoo’s hierarchical directory didn’t really scale after 1996 or so, so too app stores have not scaled as a discovery platform. Further, though there are lots of ways that the execution of the app stores could be improved, this still ultimately boils down to saying ‘Yahoo’s home page should be better’ back in 1996. Indeed it should have been, but the answer was still PageRank. And we have no analogue of PageRank for mobile apps. 

Google Now and Siri, moving down the stack, address discovery by removing the whole question of ‘which app/site/service addresses this need?’ Now tries to infer from your general activity what you might want to be told about, while Siri tries to use natural language to answer your question. Both are focused on an answer rather than a specific service - ‘sports scores’ rather than ‘ESPN’ (even if ESPN proves the actual answers). But the problem with both is that underlying answers are provisioned in an essentially manual process. Google Now, in particular, looks like Google’s most automatic and magical product, but in fact it's all editorial. Someone has to decide that Now will support cricket, and then someone has to sit down and code the cricket module. And If no-one has done rugby yet, you won’t get rugby - Now can't work out what rugby is from watching your web browsing. Siri has similar constraints: HAL 9000 didn’t have a list of things you could ask him. This does not scale to the whole internet. 

The general issue here is that any aggregator of services that offers a set of essentially hand-crafted approaches will inevitably run out of room in the metaphorical hamburger menu, just as the app store home pages can only showcase a few dozen apps at once and Yahoo's home page could only showcase a few dozen services. Or, indeed, Apple's Sherlock ran out of tabs. This doesn't scale to the internet. PageRank did and indeed the web did. 

The Baidu Maps model addresses this problem by narrowing scope to a specific domain, location, such that the discovery (hopefully) flows out of a natural pre-existing context. You don’t need to know about restaurant booking services or download the app, but you also don't need to know if Baidu Maps has an AI that can do restaurant bookings (as you would need to know that Siri connects to OpenTable): bookings are an organic extension of the context you're already in. You'll already be searching for restaurants on the map, but now ‘make a booking’ will appear.

That is, searches within maps are naturally constrained - there are only so many use cases (a dozen? two dozen?) where a service integration might make sense. So Baidu can make a maps app that’s an order of magnitude better because it contains within itself every possible maps-based use case, and nothing more. And those use cases can be hidden until you search - you don't need to find space for a 'cleaners' button - you can just show that module when people do that search, as they will.

WeChat comes at this discovery issue from the other direction: the social foundation of the app means that services can come to you thRough friends or through subscriptions to channels, but the point is the same - you don't need to find space on the screen for every single service for people to find them. For Facebook, the model would be to drive traffic out into stand-alone apps (or a web view), with the partnership being only an advertising one - for WeChat the dynamic is perhaps closer to the original Facebook platform on the desktop. 

One way to look at this, I think, is that you trade app discovery challenges for feature discovery challenges. That is, in an app with only one or two features it's easy to see what you can do, but hard to discover that app in the first place. Conversely in an app with hundreds of millions of users but also lots of integrated features, feature discovery becomes the challenge, and the opportunity. 

Changing discovery is one thing, but the other interesting thing is how much happens inside the app. There are two structural things that the desktop web has that the mobile app ecosystem lacks. On the web:

  • You can link to any resource
  • That resource will be there - you don't need to install anything.

These aggregator apps are tackling both problems: they have discovery models to allow you to get to the resource (e.g. social or local context), and the resources are loaded within the app - no need for a new app install. This isn't happening on the web, as such, but it has some of the same dynamics - within, obviously, those limited domains. 

It's interesting to contrast this with the deep linking initiatives from Facebook and Google. Facebook offers a way to drive traffic to your app from social and Google from search, and Google is experimenting with, for example, a link to Uber from within Google Maps. The problem is that if the app isn't there then you fail back to HTML, and if HTML was good enough then you wouldn't have bothered deep linking in the first place. But on the other hand, you can't integrate everything  - we already have a way to do that. Hence, the Facebook and Google moves (and also Line's) disaggregate apps, but use identity, deep links and search as an aggregation layer that is closer to the web and might be more scalable. 


That is, you can bundle things into an app that has distribution, but there's a limit to how many both for practical and discovery reasons. If you use context (maps, social) you can address the discovery problem but this works best in constrained contexts. If you don't bundle, your features are easy to discover (because your app only has one feature) but you give up those opportunities for discovery and fall back on raw search, social sharing or the app stores. 

And for all that we talk about the problems with apps and the lack of PageRank, one cannot really describe the desktop web as a prelapsarian paradise of simple and easy discovery. The web is a neutral, transparent and unmediated platform, and smartphones are not, but neither are Google or Facebook. 

Hence, as Lenin put it, the question is 'Who, whom?' Who has the traffic, and to whom do they give it? Mobile shuffled the deck, but it doesn't alter the problem. 

The other interesting comparison here is with Yahoo and AOL. The portal model failed pretty comprehensively in the 2000s, with category killer sites springing up and AOL and Yahoo and the other would-be portals falling far behind. So when smartphone apps came along we already had a dominant unbounded model that transferred pretty directly: we unbundled services from the browser, but the services themselves were already unbundled from Yahoo.

In China, though, we see a model in which the portals didn't disappear. For a lot of different reasons, the Chinese internet is based on much more horizontal than vertical competition: where we have vertical category killers (Google, Amazon, eBay) China has giants that are each leading in one category but strong in others, and competing aggressively with each other across every category. On mobile, Baidu Maps and WeChat are showing a systematic concept of the app as, well, a portal. Is this what Yahoo might look like on mobile now if it hadn't spent a decade asleep? 

App store revenue

App store revenue is not an ideal way to scope the value of an ecosystem to developers. The majority of the revenue comes from games, mostly freemium using IAP, while a large proportion of the most valuable apps are offered for free and generate revenue through other means (Facebook or Amazon, for example).

However, it does give a pretty good proxy for the broader behavior of the users, and it also of course is very relevant for developers who do want to to charge. 

For the first time, Google gave numbers for app store developer revenue at IO this year, and in the latest quarterly results Apple gave (almost) like-for-like numbers: 

  • Google said it paid out $5bn to developers from Google IO in 2013 to Google IO in 2014 (a little over 13 months)
  • Apple said it has paid out $20bn to developers in total by the end of the June 2014 quarter, and at WWDC June 2013 it gave a figure of $10bn paid to developers (at the June 2013 earnings call a month later it then said it had paid out $11bn). So in the last 12 months, it paid out roughly $10bn. 
  • Google also said at IO that it has 1bn 30-day active Android users - the degree of precision is not clear. The iOS number is fuzzier: trailing 24 months' sales would be a little under 500m, but extending that to a three year lifespan would take it to over 600m. 

Obviously all of these numbers are rounded and were given at scheduled events, so need to be taken as imprecise. The fact that four different growth rates are involved also makes calculating ARPUs a little tricky.

That said:

  • In the last 12 months, on public numbers, Google has paid out roughly half of Apple - $5bn versus $10bn, on roughly double the number of devices. 
  • On a run-rate basis, annual gross app store revenue across iOS and Android is now $21bn. 

The chart below shows the public data points. 

The problem with this, of course, is that with only two data points from Google, we don't know the trajectory - if this is a steep curve the recent period might be pointing more sharply upwards. 

A further observation: if the current market dynamics remain, Google Android's user base will at least double in the next few years - the iPhone base is still growing, but it will probably not double. However, those users will be gained at progressively lower (much lower) device price points, and with significantly lower spending profiles. 

For more discussion of why the two platforms look different, see this post. 

Finally, just to make life easier, Play is not the only payment system you can use on Android, even Google Android. A material number of apps, mainly games and mainly in emerging markets, use other payment methods. So that number might really be somewhat higher. 

Market shares and ecosystem value

Screen Shot 2014-06-25 at 2.37.00 PM.png

There's lots that was interesting in this year's Google IO, and indeed some of the absences were also interesting (no mention at all of Glass or Plus, for example). 

But we also, for the first time, got some decent numbers. Google Android has 1bn MAUs (not including China or Kindle), and Google paid developers $5bn in the last 12 months, and $2bn in the previous 12 months. 

Apple told us that it paid out $7bn in calendar year 2013 - given the growth trend, it probably paid $10bn in the last 12m. On a trailing 24m basis, there were 470m iOS users in March 2014.

 So, Google Android users in total are spending around half as much on apps on more than twice the user base, and hence app ARPU on Android is roughly a quarter of iOS. 

This is not surprising - it is entirely in line with innumerable reports from developers and publishers. It reflects a mix of several factors: 

  1. Android's market share is strongest in relatively lower income countries
  2. Many people in those countries lack credit cards and Google has been very slow to offer carrier billing
  3. Android phones average $250-$300 where iPhone average $600 - people who choose to spend the extra money are sending a signal about their intents. That is, we don't know what the ARPU for a Galaxy S5 user is, but it's probably very similar to an iPhone user - but Galaxy S5 users are a small minority of Android users
  4. Apple offers a distinctly different proposition to Android: perhaps the people who are attracted to that proposition are just more likely to spend money - that is, maybe iPhone users do spend more than GS5 users.
  5. Finally, this can become circular: if developers believe that Android users do not pay, then their behavior will be affected - they may offer a free ad-supported app instead of a paid app, or have a lower price. And if they decide not to support Android or support it second, then their users will gravitate to iPhone first, which becomes self-fulfilling. You can see this clearly on Android tablets - magazine apps have low use on Android so are slow to support Android, so users who want magazine apps don't buy Android tablets. 

Whatever your view on the relative importance of those factors (and I'm open to suggestions for more), it makes any discussion of market share complex. That is, there are lots of market shares, depending on what you're doing and where you're doing it.  


There is no way to dedupe tablet and phone devices from users who own both, so I have used phones as a consistent value in the chart above, except that of course there is no way to split this out for ecosystem revenue. I'd prefer it otherwise, but this doesn't affect the validity of the comparison. 

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