How do various forms of fragmentation of the potential audience impact the development economics? The answers will vary significantly depending on the specifics of each app but some general issues are worthy of consideration by everyone.As we pointed out recently, Android is now way ahead of iOS in terms of share of new device sales and installed base but also rapidly catching up on total revenues. The important questions for developers interested in that trend are what fractions of those markets can easily be targeted and how much will it cost to target more?
One of the most popular and frequently discussed criticisms of Android as a developer platform is the huge lag between Google releasing a new OS version and it reaching a significant proportion of devices. This is one area where Google provide very regular statistics themselves. If anything their methodology (counting devices visiting Google play within the last 14 days) will overweight the newer versions as users with older devices well stocked with apps and content may well not visit the store that frequently. Even so, the picture is not good:
This graph shows very slow penetration of Android 4.x versions in the installed base. Worse yet, since the 3.x versions were tablet-focussed and the early Android tablets were not successful in the market, the vast majority of devices are still running an OS version released almost 2 years ago. The mobile software landscape changes fast – surprisingly basic features for developers, like a public calendar API, were first included in Android 4.0. It was also the first release with a hardware accelerated UI. So, as a couple of examples, if you’re interacting with the calendar or have a very fancy animated UI then it’s likely you can only easily target less than 30% of the installed base on technical grounds alone. It’s possible to deliver similar functionality on older OS versions but requires a lot more work. It’s important to weigh up the pros and cons of using new OS features very carefully with this adoption rate. If your app requires them, the additional cost of reaching devices with older OS versions (note that ~10 million new 2.3.x devices are still activated every month) may not be worthwhile in many cases.
This criticism is rather unfairly directed at Android when in fact it’s in a similar and often slightly better position than every other platform except iOS. Until the balance of power between network operators and OEMs shifts significantly, that’s unlikely to change. It’s Apple that are the exception, having successfully insisted on controlling the OS version in all users devices directly. Apple only occasionally release stats about the number of users on a new OS version, so developers share data to make decisions on which versions to support. Even though iOS 5.0 and earlier required users to connect their device to a PC to upgrade, iOS 4.x still reached around 90% penetration of the installed base within 6 months. In 12-18 months, most developers had dropped support for earlier OS versions entirely. With the arrival of OTA firmware updates, the initial OS upgrade rate has accelerated significantly. Apple announced 100 million iOS 6 upgrades just 5 days after launch (about 25% of all iOS devices ever sold) – developers tracking penetration of their active user base saw over 30% in 48 hours – better than Android achieved with a new major version in a year. Even though iOS 6 has some disincentives to upgrade, such as downgraded maps and removal of the ad-free YouTube app, plus older devices (including 15 million+ original iPads) don’t have an upgrade available, developers are already seeing around 70% penetration of the new version. This effectively makes it safe to start working with new features of iOS for a new app as soon as they’re released and they can be adopted by existing apps, with support dropped for older versions, in a matter of months.
This is the classic fragmentation problem that has plagued mobile developers from the beginning. While iOS targets a fairly uniform collection of devices, there is still a range of screen sizes and processing capabilities to consider and test against. With Android there are multiple OEMs shipping many more device models across a much wider range of price points with a greater variety of hardware capabilities. It’s not unfair to say that there are a large number of low-end Android devices sold which are not used as much more than feature phones. However, for this reason the problem of designing for a fragmented Android device base is often overstated. Mobile devices are a much more homogenous group of touchscreen slabs than they used to be. From Google’s official stats linked above, just over 75% of devices regularly visiting Google Play are of “normal” screen size with high or extra high density displays. About another 10% are phablets or tablets with larger screens. There is a well studied correlation between screen size and user engagement across a range of activities, with downloading apps showing one of the strongest effects of this type. If “paying for apps” were also included in the studies it would be reasonable to expect an even stronger effect. As such, simply ignoring the smaller and lower density screens is a logical strategy wherever such fragmentation is an issue. Similar arguments can be applied to other hardware fragmentation at the application design level.
The fragmentation becomes an issue for testing on and supporting such a large collection of very similar devices. For all but the largest developers, owning a comprehensive library of test devices is prohibitively expensive and third party remote testing services are useful but limited in nature. In either case the time required to test fully on all devices is beyond almost any sensible budget. As such, early users become testers and developers rely on crash analytics and bug tracking tools to get their apps working properly across the long tail of device models. In many cases developers would choose to avoid fixing a complex bug that afflicts only tens of users with obscure devices if not for the fear of disproportionate negative reviews. Currently it’s only possible to do damage limitation by preventing new users with a known incompatible device from downloading the app. If Samsung’s dominance of the Android device market continues it wouldn’t be surprising to see developers use this feature to target a known fully tested set of devices initially and only add others after they’ve been tested by a “friendly” user.
For developers interested in directly monetizing their apps through paid downloads or in-app purchases, this is very simple. For iOS, distribution is only allowed through the app store (with special exceptions for internal enterprise apps) and Apple sets prices and makes payment mechanisms available worldwide. For Android, there is Google Play and then there’s a decision whether or not to also publish to Amazon’s store and maybe some of the other smaller 3rd party stores. This will get more complicated as OEMs attempt to piggyback the Android ecosystem with new smartphone platforms – BlackBerry 10 and the newly announced Sailfish OS from Jolla both include an Android runtime environment.
The major distribution issue arises for those who simply want the greatest possible reach, whether that’s to monetize through ads, or some other mechanism outside of the app stores. Again, on iOS there is no issue, the app store is the only (non-jailbroken) way. For Android though, there are a truly astronomical and rapidly growing number of potentially compatible devices outside the Google ecosystem. Outside of Amazon’s own Kindle branded devices, we have deals with operators to pre-load their store in a prominent position. Is this the start of a trend where the networks attempt to limit Google’s control over the ecosystem by partnering with rivals? Then comes the truly giant volume of unofficial Android devices, predominantly from China. There were somewhere around 40-50 million Android devices sold in China in the last quarter, all of them without access to paid content on Google Play and many of them with no access to Google services at all. Some of these devices are also being sold outside of China; although this is a small market at the moment it’s likely to grow. Android allows direct distribution of apps but how do you reach all of those users? If you can, how do you manage the other forms of fragmentation without a store or reliable information from the device manufacturers?
Apple have relatively little fragmentation, that said, they’ve just added a new resolution and a new physical screen size for an existing resolution. They must be getting close to saturation at their current smartphone price points so for continued growth in the medium term they’ll have to create either another form factor to sell to their existing user base, or a lower cost device to reach a larger market; either way there’s more fragmentation for developers on the way.
Android is likely to improve a little this year as version 4.x expands through the installed base and some older devices drop out. This should reduce OS fragmentation, at least temporarily. However, the factors that caused it to occur in the first place have not gone away. While we have network operators and OEMs around the world trying to avoid commoditization through differentiation, there will be fragmentation of hardware, software and pricing. Since there’s a greater than 10x difference between the (unsubsidized) price of the cheapest Android phone and the most expensive, developers can’t expect to target a single optimum experience at all of them without great difficulty.
Even with Android’s current lead in device sales, iOS still appears to be some way ahead when it comes to ease of targeting a large and monetizable user base. As the global app revenues for Android catch and eventually overtake those for iOS it will be important to watch out for the distribution of those revenues. Will various forms of fragmentation of the platform are mirrored in the distribution of the revenue, or will it be concentrated in the high-end Google approved devices. If it’s the latter then Android could finally become a more financially attractive target for developers than iOS. That’s still quite a big “if”.