The Guardian’s Charles Arthur tweeted the graph above and an article yesterday looking at how time spent on mobile devices breaks down across apps and the mobile web. Mobile, so long the place the advertisers failed to make an impact, is now big ad business (and both The Guardian and Microsoft Advertising have a vested interest in fanning those flames given that they are both advertising media owners).
The Flurry data in Charles’ article (shown below) gives a bit more indication of how that time breaks down in the US.
“Apps more popular than mobile web” says the headline. Popularity judged by time spent, however, is a bit of a risky assumption, and “popular with whom?” is something else that is worth exploring.
As you can see from the US data, there are some disproportionately time-hogging types of apps. Games make up 1/3rd of all time spent. Good games are really engaging, and so that should come as no surprise. In the UK it would be really interesting to see where the BBC iPlayer now ranks in terms of total smart device time consumption, because increasingly they make up the biggest proportion of use of the service. Full TV programme streaming services, like games, have a higher likely dwell time than, say, doing a web search.
Facebook have shifted their focus in recent years to mobile, and particularly to mobile native apps after some unsuccessful experiments with HTML5 as a technology to underpin their mobile apps. If you put the full weight of a large organisation behind achieving something fairly specific, it is likely to happen. That Facebook app usage is so high reflects partly the sticky nature of the application, and partly the achievement of their primary objective (monetising mobile use).
But, and here’s the big but, time spent on types of application (whether App- or browser-based) is a very shallow indicator of user popularity, and is a very old-school media advertising view of the world. “Eyeball time” is very meaningful if you are selling ad space, but ad space-based apps aren’t everything. There are a wealth of business models that might underpin an app or a mobile web service that aren’t necessarily about monetising through advertising, purchase price or in-app purchases.
Take, for example, if I wanted to book a cab. A long time spent on an app that is there to help me to book a cab isn’t a good thing – it’s a really bad thing. I want to book a cab quickly and effectively. If I’m spending a long time on your cab-booking app or mobile web site, it’s probably because it’s crap.
But as the app hype continues, the assumption that everything needs to be done as an app continues to reinforce itself, and then companies devote more money and resources to building apps, so that in turn they become more popular. Where’s the user benefit in all of this? In many cases I’d argue there isn’t one.
On the one hand, how many apps being knocked out today deliver one or more of the seven reasons to app I identified a couple of years ago? Many do not, and also become infuriating in the process.
Take for instance apps that will notify you of something new, maybe even giving you part of a message in the notification, but then can’t allow you to access this when you have no network connection. The Twitter and LinkedIn Android apps are both guilty of this – particularly annoying when on the Tube and you can see there’s something waiting for you, but the App hasn’t cached it already to make it available until you’re next in view of a network.
Along side the “we must build an App because we must” thinking is the other bete noire for mobile web, responsive design. I’m fully with Jakob Nielsen on this one: good mobile web design means designing well for mobile devices. Responsive design solves an administrative problem for web designers of having to deliver to multiple platforms. A responsively-designed website is usually in no-way contexually sensitive to mobile, and is a half-arsed experience as a result. No wonder, then, that apps are “more popular” if that’s where the contextual sensitivity resides.
Want some good advice on all of this? Check out Tom Loosemore’s blog from the Government Digital Service. Short version: design your service really, really well for mobile web. Then think about whether you need an App.
mmitII 
I’ve come to associate “responsive design” with “crappy experience on desktops and laptops.”
“time spent on types of application (whether App- or browser-based) is a very shallow indicator of user popularity, and is a very old-school media advertising view of the world.”
It’s a pretty good start, though.
Your point about the cab app is a good one, but here’s the problem if you’re a cab company. Do you want people to find you and use your service through a mobile web search – liable to huge variations, SEO poisoning, fickle search engine ranking – or through using your app? You can be sure that if your app is on the phone then there’s a better average chance of the user going for your service than if you’re only found through a web search. (True, you could offer a mobile web page link, as many do).
The ideal thing is to be an app, in that circumstance, and offer the download/link to anyone who comes along on the mobile web. Depending on the cost of the app development, though, you can feel more confident of its ROI than leaving yourself to the seas of mobile search.
And users seem to chime with apps. It’s what they do on smartphones. So it’s also self-reinforcing.
Discoverability as an app is a nightmare, though! At least with pure web search you can pay to get to the top of the results (either through search or SEO). Sure, once your app is on the device it’s in the better interests of the provider. But how do you get it there in the first place?