In recent months, there’s been a steady drumbeat of stories about the coming death of apps. The reasons for this claim are several and include slowing growth rates for the top 100 apps, the rise of bots as an alternative to the app model, or a general sense of dissatisfaction with the state of apps. This week, however, Apple hosted its annual developer conference, WWDC, and demonstrated the era of apps is far from over. Apps are evolving and it’s worth looking at both the true state of apps today and how that’s likely to change over time.
50 Billion Reasons for Skepticism
Let’s start out with the financials. Apple reported this week it is about to pass $50 billion in total payouts to developers. That, in turn, implies a total gross revenue of around $70 billion from Apple’s App Store alone. That number by itself is impressive – only 66 of the world’s countries have a greater annual GDP. But it’s also notable for what it says about the trajectory of the App Store, which is best shown visually:
As you can see, based on the periodic data points Apple provides, that number has been growing faster, not slower, over time. In January this year, Apple announced customers had spent $20 billion just in the past year, while the new figure from Apple puts the increase in developer payments alone (just 70% of total spend) at $10 billion since then, in about six months. Clearly, the largest participant in the app economy is doing just fine despite the supposed demise of apps. For what it’s worth, I suspect we are entering a period of maturity for app stores, in which the vast majority of users have downloaded the most popular apps already and, as growth slows, there will a shift to the long tail of apps among existing users, while a smaller number of new users download the top 100. But the total audience for apps has never been bigger and there’s little evidence this trend will slow app store revenue growth or even total downloads.
Bots Aren’t the Threat They’re Made out to Be
Bots are a fascinating new element of mobile user interfaces and have potential in certain well-defined use cases. However, as a threat to the app model, they’re fundamentally limited for a couple of reasons. First, bots are not a fit at all for the vast majority of apps. Put another way, for the apps that generate the vast majority of revenue. Consider that roughly 75% of app store revenue globally comes from games, a use case for which bots are entirely unsuited. That means 75% of app store revenue is entirely untouched by bots. But it really goes further than that – productivity apps such as Microsoft Word, note-taking apps like Evernote, social networking apps like Facebook, video apps like Netflix, photo editing apps like Instagram or VSCO, e-readers like Kindle, and many other apps in many other categories are equally impervious to the threat of bots.
Bots may, in time, encroach a little more on new categories, but the vast majority of things bots are useful for fall into two camps: B2C interactions, and reference. Given the focus on B2C interactions, it’s no wonder three of their biggest proponents are companies with a vested interest in fostering activity in that category: Microsoft seeks to dominate enterprise software, while Google and Facebook dominate online advertising by businesses to consumers. But apps which provide that functionality are a tiny minority of those in the various app stores and generate even less revenue (mostly because they’re merely customer interaction interfaces for businesses whose revenue is mostly generated elsewhere).
The last counterpoint to the idea that bots are a threat to the app model is that, of course, bots exist more or less exclusively within apps. Whether it’s Facebook Messenger, Google’s Allo, Microsoft’s Skype or some other version of the concept, all are themselves apps which are downloaded in the traditional way. Yes, some revenue opportunities and time spent that would in the past have gone to app stores may now accrue to these platforms instead, but as we’ve already seen it will be minimal and, in any case, any in-app purchases will still go through the major app stores.
Apps aren’t Dead, but They’re Evolving
The other thing to note is the meaning of the word app is very different today from its meaning in 2008, when Apple’s App Store launched, something I’ve written about previously. As I wrote in that earlier piece, Apple has been at the forefront of evolving what apps look like and one of the biggest changes has been their escape from behind the rounded rectangles into other facets of the operating system. Even before this year’s WWDC, that included 3D Touch, Notifications, Widgets, keyboard and content blocker extensions, and more. At this week’s event, though, we saw it evolve still further with the extensions model applied to Siri, Maps, and iMessages, more interactive widgets and notifications, VoIP apps on the lock screen, and more. As the concept of an app continues to evolve, it becomes better able to resist the encroachment of alternative models onto its turf. The opening up of iMessage, Siri, and Maps in particular will change the way apps are presented to users, but that process will still begin with a download from the App Store. The same goes for many of the other virtual assistants out there, most of which will either constitute apps themselves, or rely on installed apps for some of their functionality.
Google, of course, is also evolving the app model, most recently with the announcement of Instant Apps, which itself builds on the concept of app streaming. Neither of the two companies which dominate app downloads worldwide is standing still. That’s why the app model will continue to be robust despite the rise of alternatives. Some of those alternatives may carve off tiny slices of the overall opportunity, while others will morph until they become part of the app model itself. But the app model is here to stay, even if it might be hard to recognize by the time it reaches its tenth birthday three years from now.
What I find interesting is that Apple’s approach to apps and Google’s seem to be diverging.
In the beginning, both simply copied the PC app model. However, Google’s instant apps now look like an attempt to make apps more like websites. The only differed being that instead of loading JavaScript, you will now download native code. The idea is to make apps thinner. On the other hand, Apple’s approach is to add apps on top of their ones, making their apps thicker.
The Google approach is great for discovery and when your interaction is the first step on a workflow. Apple’s approach is great when you want to add something to a context/workflow that is already in progress.
This divergence will make it harder for the full functionality of an app to be ported from iOS to Android and vice versa. It will make the experiences on each platform very different.
This is also why it would be very interesting if iMessage was ported to android.
“However, Google’s instant apps now look like an attempt to make apps more like websites.”
Anyone know whether ChromeBooks run Android instant apps today? If not today, has the Chrome team promised to run IAs soon?
That’s a very interesting way to look at it.
I don’t know for sure, but I’d bet they will. The ChromeOS-Android integration is very deep (they “Share To” each other, concatenate alerts…), I’m fairly sure ChromeOS will be able to call up Android’s Instant-app mechanism and obfuscate the Android container.
I’m unsure of the status for OSes that still use ARC (MacOS, Windows, Linux). Maybe they’ll get instant apps too ?
Apple’s approach seems to mimic their Services idea in OS X, where an installed app could add it’s functionality system wide under the App Menu>Services. I always liked that and used it, but it seems to have lost favour if not function.. This seems a bit more promising than how it played out on the desktop.
Joe
There is a spectrum of what these extensions/add-ons can do, and I think that the MacOS X Services were on the the very restricted side. On the other end, we have things like browser extensions and plug-ins, which tend to be security holes, but are also very flexible and powerful in how they can directly control the content on the screen.
What Apple is doing with iMessage seems to be there with browser extensions, or even more flexible. I also expect that they have done this with utmost attention to security.
Facebook had great success with this model, supporting very popular games like FarmVille. My thinking is that this business model has already been proven, and that success is more or less guaranteed by history.
Also, an important main difference is control:
Google’s approach is open and web based; you can put any instant-app on any web page, Google doesn’t care.
Apple’s approach is very controlling and proprietary, vetted apps/services can integrate with some of their apps in the prescribed way using bespoke APIs.
I’m not sure Apple’s approach is systemic enough (yet ?) to make much of a difference. We’re talking about a handful of providers being validated to integrate into a handful of Apple’s apps. That’s not enough scale to prevent Google from doing the same thing directly within their own code, I’m sure the relevant 3rd parties will gladly accept to be linked to, especially those that don’t monetize via ads. That might change if Apple opens the floodgates. If.
Yes, Google is more “open” and web based. That’s for sure.
However, we’ve seen this closed approach succeed before in WeChat for example. I also think the original Facebook app model (FarmVille for example) proved that this can work. Having a wall around the garden isn’t a limitation if the garden itself is large enough.
The issue with Google of course, is that they do not control a popular messaging app on their platform, and as for maps, it is possible that Google’s business model precludes them from opening it up in the same way as Apple. From a technology perspective though, of course Google could do the same thing. The question is rather, will they, and what Android apps do they control where it would make sense?
Google’s messaging issues are weird. They aren’t even succeeding in competing with platform-locked iMessage. With their huge “is-default” advantage.
And instead of fixing what they do have (Hangouts is OK except for video calls), they’re introducing Yet Another messaging platform. Or two. They need to stop with their “project du jour” approach and start sticking with stuff.
Also, I think the two approaches are unrelated and not mutually exclusive. You could do both, or neither, and they don’t really impact each other (except in the compound case of an instant-app calling a 3rd-party service, but that’s not even really a special case) . What’s interesting is Apple focusing on one, Google on the other.
Yes, totally. I do think there is a strategy behind each companies focus though.
Apple would do well if they could differentiate their devices (+ software) and commoditise the services. That is to say, if they lower the barrier to entry of services and increase the number of competitors in that space, then they will commoditise that layer, and make themselves relatively more powerful. This is Porter’s Five Forces. Apple is doing this by giving a powerful distribution platform in iMessage, reducing sign-up friction via Apple Pay, and by providing a common entry point in Maps (and iMessage).
For Google, it is the other way around. They want to commoditise the device and differentiate in their cloud services. They have aggressively lowered the barrier to entry for hardware OEMs, created a hyper competitive situation, and commoditised Android devices. They don’t want competition in the services which they monetise, and in particular, it is highly unlikely they will open up Maps in a way that 3rd parties will control which services Maps will tie up with.
So although these approaches are not mutually exclusive, I do think that Google’s Instant Apps approach is incompatible with Apple’s desire to enrich the user experience inside their apps. Conversely, Apple’s extension approach which invites multiple services into their apps, tends to conflict with Google’s service monetisation strategy. So these approaches are not mutually exclusive between themselves, but in effect, we won’t see them together.
What’s interesting too are the consequences of these choices.
For Google, it’s the race to the bottom and the update mess.
For Apple, it’s security, quality, and ergonomics issues.
The big counterpoint to this is that even Google’s Instant Apps are only appropriate for certain use cases, and still include the option to install in the traditional manner. As such, I’d be careful to characterize this as a broad shift for Google apps – to my mind, it’s just another example of apps evolving in subtle ways, none of which is indicative of a single future direction.
App as we know it is dead
i think App is evolving and will unbundle between to value content just as website because gamers are the only group making real money creating app on mobile.
Agreed.
The issue with apps is that they fragment the experience by some random feature set, instead of by task. I don’t want to call up my calendar to check my appointments, then Maps to know where it is, then Uber to call up a car. I don’t even want to juggle different messaging apps, I want to type a message and let the OS to choose the way to pass it on by itself.
Yet going meta on all those apps/services is probably hard for technical, ergonomics, security and revenue/hits attribution reasons ?
I also think it is difficult for categorical reasons. I think it is human nature to categorize tasks. Especially when all the tasks (such as in your example) also exist independently of, say, an appointment. I think we, as the user, contribute to fragmenting the experience by old habits, some developed pre-computers. And many just from Modernity influences. We are a culture built on specialization and less by collaboration or broad, comprehensive understanding.
From a business side, I think branding becomes an issue, too. If my service is part of a bundle, then my expertise starts to get conflated and obfuscated. And what if someone starts to blame me for an issue another actor is causing? Unless my brand can be preserved and some sort of mental sandbox can happen (such as having an Uber icon available instead of a generic “car service” notable, or even the service hidden and automated) that helps to say “This is what I provide, and I ONLY provide” it is hard to see the benefit of fitting into a background process.
This is not to say I disagree with you. This is only fleshing out the difficulties you already suggest.
Joe
Agreed.
Not only are there different taskflows (?) and different levels of atomicity, there are probably also different user profiles. Same as for apps, options, tools, some will probably want the freedom to choose their own providers and build their own workflows, others will probably prefer something simpler even if less rich/flexible/versatile.
It’s not only a matter of doing it well, but also of striking the right balance between ease and flexibility for one’s audience.
We always follow your beautiful content, I look forward to the continuation.
I appreciate you sharing this blog post. Thanks Again. Cool.