Statistics on Internet Traffic – Tablets and Mobile Phones Compared

by Eduardo Casais – Part 2 of 2

Editors Note: We welcome posts from people interested in Device Intelligence. This is the second  of 2 posts that come from Eduardo Casais. Eduardo has been working on Internet technologies since 1997. He has been involved in projects dealing with IP over ATM networks, WWW transcoders for TV set-top-boxes, and service platforms for telecom operators. He led the development of the WAP protocol stack and content adaptation facilities for the Nokia WAP Gateway, and has been an invited expert for mobile Web best practices at the W3C. He has patents on mobile applications and protocols to his credit and contributed to the WURFL device description repository. He currently works in Switzerland as a consultant in the area of mobile Web.

Two mobile market segments
In a previous article, we derived from ScientiaMobile MOVR Internet traffic statistics a few guidelines regarding OS compatibility targets and device pools to test websites and apps for mobile phones. Tablets are endowed with more physical screen space, are mostly operated in a stationary context and always with both hands, and are sold and provisioned through substantially dissimilar, albeit overlapping, channels; hence, that device class warrants a specific analysis.

Figure 1: Device diversity with proportion of traffic covered by the top-10 models.

It makes all the more sense to study tablets separately from mobile phones since those two types of terminals are also readily distinguished by their Internet traffic profiles and the diversity (or lack thereof) of their platforms – as illustrated in figure 1. The chart places each category of terminal within a coordinate system determined by the degree of concentration of the installed base with respect to manufacturers and to operating systems. Each axis corresponds to the Herfindahl-Hirschman index, a standard measure varying from 0% (an infinity of entities with the same weight) to 100% (a monopoly). Furthermore, the coloured portion of each point in the chart is proportional to the fraction of the traffic actually covered by the top ten devices in each category and continental region.

Observations for mobile phones huddle on the left part of the graph. They exhibit a high concentration along the OS axis, reflecting the dominance of Android; a high diversity of vendors, despite the prominence usually given to Samsung and Apple; and a very small share of traffic originating from the top 10 devices, the consequence of market fragmentation by a myriad handset models. Tablet data, on the other hand, stretch across the graph, with two obvious extremes: Africa, whose profile resembles those of mobile phones; and Oceania, a nearly Apple monoculture where a handful of iPad models generates the bulk of Internet traffic attributable to tablets.

In that context, let us answer again the two questions: which OS versions should developers target for mobile services? Which devices should they use for testing?

Operating system compatibility
Table 1 gives the vintage of operating systems covering 90%, resp. 50% of tablet traffic, both in years and as version baseline (rightmost two data columns).

There is a substantial age discrepancy between the Android and iOS segments. iOS tablets exhibit a time to 50% quantile of 0.5 to 1.2 years (depending on the region), and 2.1 to 3.9 years for the 90% quantile. In comparison, mobile phones typically run a “fresher” iOS version: the 50% quantile is 0.4 to 0.6 years, whereas the 90% quantile is 1.2 to 2.0 years. Conversely, Android is generally “staler” on mobile phones, with a range of 4.1 to 5.2 years for the 90% quantile, against 3.9 to 4.3 years for tablets. Because of the predominance of Android, tablets feature more recent software than mobile phones on the average.

The baseline gives the minimum set of backwards compatible OS versions required to cover 90% of the traffic, and is therefore relevant to an organization maintaining an existing application. A firm launching a new app in Summer 2015 would have had to release it for iOS 8.0 or higher to comply with certification rules imposed by Apple from June onwards. In this situation, pushing back the Android baseline to 2.2 in Europe and 2.0 in North America, and throwing Windows RT 8.0 into the mix achieves a 90% coverage in those regions; in the rest of the world, no adjustment is sufficient – such was the backlog of users who had not yet upgraded from iOS 7.x.

When releasing a completely new app on the most current iOS and Android versions (resp. 9.2 and 6.0 at the time), with only forwards compatibility as a requirement, how long would it then take before 50%, resp. 90% of the users can effectively run it on their terminals? The answer is given by reversing the interpretation of the leftmost columns: in North America, for instance, it would take 0.5 years to reach 50% of the iOS market, and 2.2 years to reach the 90% mark. With Android however, 2.2 years are not even enough to cover 50% of the traffic: 2.3 years are necessary – and it lasts as much as 4.3 years before reaching 90%. The time constraint on market reachability is therefore set by the migration rate of the Android installed base.

Considering that only iOS imposes a restriction on the baseline, what would be the delay if one published an app backwards-compatible with Android 4.1, but running only on the newest iOS version (i.e. 9.2) at the end of 2015? The answer can be deduced in the same manner. Thus, 0.5 year suffices to cover 50% of the traffic in the North American iOS segment, and 2.2 years for 90% – and therefore to complete the desired coverage for the entire tablet market, since backwards compatibility with version 4.1 already caters for the Android market adequately.

As a final scenario, what if one developed an app backwards-compatible with iOS 8.0 and whatever Android version as originally set (i.e. 4.1 in North America)? This configuration ensures immediate coverage at the 50% mark for iPad users everywhere. The values for the 90% traffic quantile are not tabulated to avoid clutter, but they are trivial to compute: it is one year in every region.

Device testing
Entries in table 2 are derived from the ten most popular terminals by applying the same procedure carried out for mobile phones. Constructing the “global” test pool basically amounts to acquiring a couple of new tablets annually and working with the set accumulated in the past five years. A comparison with the entries for 2Q2014 shows that a test pool constructed in this manner remains quite stable over time.

Given the data on OS vintages, it is no surprise to find old devices in the test pool. Just as with OS versions, we can appreciate the information retrospectively or prospectively: in 4Q2015, a website or app had to work flawlessly on a 4.8-years old iPad 2 or a 5.2-years old Galaxy Tab. Four and half to five years from now, a future instance of a website or app will have to work flawlessly on a brand new (at the end of 2015) Samsung Galaxy Tab S2 or Apple iPad Pro.

Concluding Remarks
Market reports usually delve into the percentage distribution of software versions for various mobile platforms of interest. Mapping those percentages to durations provides an equivalent, directly operational input for product managers to shape their delivery roadmaps – assuming of course that neither OS market shares, nor OS upgrade rhythms shift appreciably compared to their historical record. Whether expressed as the length of time during which backwards compatibility must be guaranteed, or the delay before the installed base is able to execute a novel app, the lesson is sobering: this may be, and with Android it definitely is, a matter of years. Without such diachronic aspects, the absolute market share of a software platform does not give a faithful indication of market reach.

Furthermore, contrarily to the widespread perception that people replace their mobile devices biennially, tablets and handsets alike are remarkably long-lived, with popular models exhibiting continued high usage years after their first commercial availability. Hence, developers cannot presume that the installed base is essentially made up of recent terminals with modern hardware and an up-to-date software platform.

The statistical evidence and constraints imposed by app store administrative policies point to Web technology as the most adequate basis for mobile services intended to be swiftly adopted by an overwhelming proportion of end-users. Well-established methods render a website compatible across browser versions (progressive enhancement), with proxy-based browsers devoid of usual scripting capabilities available on client software (graceful degradation), and with entry-level and legacy devices featuring restricted or obsolete software (server-based content adaptation).

On tablets, a Web-based approach looks even more appealing, since their fairly large displays are very well-suited for responsive website design. Apps take over for applications requiring complex user interactions, like multimedia e-books. On mobile phones, the Web should logically remain the tool of choice to deliver universal services on multiple form factors and device generations, leaving apps as the ideal implementation for device-centric programs like games, and for innovations, such as augmented reality, taking advantage of the wealth of embedded digital sensors.