The handset browser’s reign as the largest data consumer on the wireless web looks to be ending, with mobile Internet traffic now evenly split between browsers and apps.
Zokem, a market analytics startup based in Espoo, Finland, shared numbers last month comparing minutes used by browsers versus those taken up by apps. The browser, a universal function that works across any platform, still commands a high amount of users’ time. But according to Zokem’s data, users spent even more time with apps like Twitter. Use of the social network, for instance, averaged 311 monthly minutes, compared to 300 for the browser.
The Zokem study, based on a dataset of 10,000 smartphone users in 16 countries, indicates that just two years after the iTunes App Store kicked off the mobile app economy, consumers are fast moving on from the “old days” of relying on a mobile browser. Indeed, between iOS and Android devices, over 7.8 billion mobile apps have been downloaded since 2008. That’s music to a mobile app developer’s ears, and helps partially explain why Apple, earlier this year, paid out more than $1 billion to third-party developers in revenue sharing for iOS applications. This consumer move to apps also gives hope to Android programmers, many of which are still waiting to reap the rewards of Android’s rapid growth.
As apps continue to gain popularity, developers will need to be more mindful of how much data their apps consume, and I wonder what impact of the HTML5 web standard will have on data consumption in the long-term. More importantly, as apps eat up more data due to additional functionality, how will developers contend with the inevitable tiered mobile broadband pricing?
Can HTML 5 and Data-Efficient Offerings Reverse the App Trend?
If HTML5 apps are the future, this trend of apps eating up more data than the mobile browser could reverse. Why? For starters, in HTML5, the browser is the platform; developers need not worry as much about being able to support multiple operating systems (iOS, Android, webOS, BlackBerry, Windows Phone 7, Symbian and any others) so long as the most common mobile browsers embrace HTML 5, which seems likely.
Why would they? Because as my colleague Simon Mackie pointed out a few months back, HTML 5 adds functionality such as in-browser video and vector graphics, geolocation awareness, in-browser storage and drag-and-drop support, not to mention localized app storage and offline usage. Put another way, HTML5 apps with such collective features could rival, or eventually supplant, native apps in terms of functionality. They would also appeal to a greater number of devices without requiring major code changes.
Alex Kessinger, a front-end engineer for Yahoo!, shares my enthusiasm for the potential of HTML5 apps on mobile devices:
“Yes, [mobile] is the hotspot for HTML5 apps. The iPhone has very sweet integration and your app can live on the home screen among all the other apps (see my tutorial on how to do this). The Android has support for the HTML5 APIs required, but not as nice of an integration. Over the next few years, the number of devices that are running HTML5-capable browsers is going to skyrocket. Besides just the amount of devices, the different types of phones and phone OSs you might have to develop for will also increase. It is going to make a lot of sense for a portion of app developers to target HTML5 because it will be able to run on all of these devices, and you won’t need to worry about all the underlying disparate technologies.”
An example of this is YouTube, available as an app on all the major smartphone platforms. Streaming video via a YouTube app surely eats up gobs of wireless data; because the video is consumed within an app, that bandwidth is attributed to apps in the Zokem study. But YouTube is already offering an HTML 5 solution for streaming videos in the desktop browser; such functionality is sure to come to mobiles.
Nokia, too, sheds some light on how developers and carriers can reverse the issue of apps consuming huge quantities of data. During September’s Nokia World event, I was bombarded with repeated examples of how Nokia “gets” the mobile space like nobody else. The company’s Ovi Maps is considered a “data-efficient” app. The offering keeps most of the data local to a handset and, I was told, uses far less than that of Google Maps, which relies on a fairly consistent and relatively higher bandwidth data connection. And by maintaining fairly static map data and only requesting variable data such as directions based on location, Nokia touts a far more efficient app when it comes to bandwidth use. The latter is a key factor in emerging nations, where mobile broadband is scarce, slow or expensive on a per MB basis.
How Will Your App Cope With the Demise of Unlimited Data Plans?
Optimization of mobile data in apps isn’t a new problem, but I expect that it will face greater scrutiny from app developers and consumers as we move towards tiered pricing models for data, and, as my colleague Stacey Higginbotham discussed earlier this year, the finite amount of wireless spectrum is gobbled up by data-hungry apps.
For now, carriers plan to combat spectrum scarcity with usage-based plans, a practice already underway at AT&T. Instead of unlimited data plans, the carrier offers data in 200 MB and 2 GB amounts: Use them up and you have to buy more data. Consumers could, in response to this, choose “data-efficient mobile apps” such as Nokia’s Ovi Maps, over the likes of Google Maps, for example. Mike Rowehl, a mobile systems developer for the past nine years, summed up the challenge nicely in an email discussion on the topic:
“In developing any networked app there’s always a tension between download/sync and load-on-demand techniques. If we move more and more toward tiered or metered plans, that could definitely tilt things toward the load-on-demand architectures in terms of simplicity. But the decisions there are really application-specific. Some apps will consume minimum bandwidth when you sync all data and run operations locally, others will invalidate data so quickly that managing the cache consumes more bandwidth than simply loading on demand.
The problem of needing to reduce client/server chatter in mobile applications isn’t a native only problem however. HTML5 has offline app support and local data storage capabilities for exactly this reason, even web apps on mobile have felt the need for techniques to minimize bandwidth. If load-on-demand was always the answer web apps could behave exactly like they do now. The need to support sync/download as a method of keeping apps fast is one of the reasons for those new features.”
Rowehl’s points are spot-on, and while most developers are already likely considering how their connected apps use bandwidth, a future of paying for every sliver of data used may dictate a stronger focus on bandwidth efficiencies from developers.
To that end, let me share some basic best practices of data use in apps. These might appear as “common sense,” but in fact can easily be overlooked when developing a mobile application:
- Only pull incremental data when possible; don’t refresh whole databases, for example.
- Add numerous sync options to your app, so that polling can be as often or as infrequent as needed, per the user’s needs.
- If appropriate to your app, include a manual sync option.
- Offer an option to track the data consumed by your app; make that information accessible to the user.
- Consider following Nokia’s lead and taking advantage of greater storage capacity on handsets by providing more local data for your app and less need to pull from the web.
Rowehl stressed an additional related point that could count as a sixth item on our list: Consider service offerings and platform tools from third-parties that have data syncrhonization expertise. Funambol, for example, provides tools and servers for SyncML; RhoMobile offers the Rhodes cross-platform framework with synchronization services.
In the end, though, choosing to manage your software’s appetite for data by yourself of through tools such isn’t the most important step to consider. What matters most is keeping apps on a data diet, or else you run the risk of consumers looking at a competing program with similar functionality and better data efficiency.
Related Research: HTML5’s a Game-Changer for Web Apps