This recent article on Android fragmentation ( ) triggered some thinking on the impact of fragmentation. Fragmentation has generally been viewed very negatively, although Paul Thurrott offers a (sorry, paywall). Thurrott’s basic argument is that any individual user only cares about the particular device they own, not the vast pool of Android devices and overall app coverage on Android seems pretty good. Paul is generally thoughtful, but this is a shallow analysis. Even new phones are no longer guaranteed to have the latest version of Android contrarian perspective When iOS and Android came on the scene, one of the stunning points of differentiation in the mobile OS ecosystems compared to desktop OSs like Windows was the rapid and regular updating of existing devices with new versions of the OS, including major new versions. This rapid and automatic updating extended to the app ecosystem as well, supported by OS infrastructure. Looking at Apple’s business model, which is primarily focused on selling new devices, the decision to upgrade existing devices for free might seem confusing. Why not leave those old devices looking more and more outdated in order to incent users to buy a shiny new device? If one looks through the eyes of the app developer, the strategy becomes clearer. The deep moat around any OS platform is the huge ecosystem of applications that have deeply leveraged OS APIs. This moat is continually dredged deeper by new applications and existing applications staying current and taking advantage of new OS capabilities. Some of these APIs create internal network effects where the value increases to the user with every application that adds support. The simplest example of this type of API in the desktop world was rich copy and paste. In the mobile world, deep linking and sharing support are examples of features that get better the more applications that support them. These are the kinds of APIs where it is especially important that the app ecosystem stay current on new OS innovations. For an application developer, an OS ecosystem that provides a singular target API and a unified pool of users on that API vastly simplifies the cost/benefit analysis about whether to do the work to support a new OS feature. Every app development team is triaging features — making decisions about whether to invest in features internal to the application, features that leverage OS capabilities or whether to invest in some other OS. The development team is always balancing the cost and benefit of that work to their business. When an ecosystem is growing very rapidly, it is easy to focus on new devices with the latest OS since that represents a significant and growing percentage of the overall user base. As growth slows, the existing base of devices starts taking on larger importance around decisions of where to invest. Fragmentation in that base becomes more impactful. Of course new OS capabilities that require new device functionality (e.g. biometric sensors) are clearly limited to new devices. In the case where new hardware and new OS APIs surface as clear new application value, the decision to support those APIs, even in a restricted set of devices, is still pretty clear for an application developer. Although Android had similar updating capability to iOS, in practice the friction introduced by the diverse Android ecosystem led to fragmentation very early on. From Google to key silicon manufacturers to device manufacturers to the carriers and then the end users, every stage introduces opportunity for delay in getting updates to users. Early fragmentation also came from variation in low level chipset support all the way up to the custom user interface shells by Samsung and other OEMs. Wide variation in screen sizes and resolution also led to significant fragmentation. There are literally tens of thousands of different Android devices that have come to market. Google has been working to address this for a while. Google Play Services, which exposes many critical application APIs, is updated independently and offers a more consistent cross-ecosystem target for the APIs it supports. Google is also working on to speed OS updates through that pipeline of silicon builders, device manufacturers and carriers. Project Treble In practice though, the typical app team still has to spend significant cycles dealing with these fragmentation issues. These issues distort all cost / benefit analysis. The aggregate effect is both to reduce investment in staying current on new OS capabilities as well as bleed off investment to deal with the overhead introduced by all this fragmentation instead of building great new features. Overhead occurs as the team plans, builds, tests and supports any new feature. The consequence is to reduce the quality and number of Android applications. This has direct and immediate impact on every Android user. Thurrott’s argument is “the only thing that really matters is the apps, and all Android apps work just fine”. The bar of “just fine” ignores this whole aggregate effect. It is certainly the case that smartphones, like PCs before them, have reached some level of device sufficiency. Thurrott argues that the recent Android releases have been “pretty minor” with regards to new platform features. Of course, that is exactly the decision making and effect one would expect if such features involve high overall cost for little aggregate impact because of the difficulty of pushing them end-to-end through the ecosystem (including especially application support). Windows also suffered heavily from fragmentation, device sufficiency and loss of leverage and mindshare with application developers. An important consequence was to spend more and more investment on features that would “just work” without app support rather than requiring large ecosystem investment. This distorted decision making and resulted in worse outcomes. I find it interesting that some of the most powerful technical moats with network effects (e.g. these OS APIs or the Office file formats) have this very messy boundary effect that can cloud analysis. For file formats it was “how compatible is compatible enough”? Every competitor provided some level of interoperability. For some users, using some set of features, that interoperability was enough. But in aggregate file format compatibility was, and continues to be, this amazing technical moat. OS APIs have a similar characteristic. How important is any single new API? How important is it that some application support it? It can’t be very high. And yet the aggregate effect is this immense technical barrier. Android’s fragmentation is a big deal that has real and immediate end-user consequence.
