Category Archives: Operating Systems

Google, Andromeda, Mythology and Hubris

Next week, Google is expected to unveil a new operating system named Andromeda, which in some ways combines the existing Android and ChromeOS operating systems. The choice of name is interesting – Andromeda is a figure in Greek mythology, and it’s worth briefly recapping her story. Specifics vary depending on the version of the story you consult, but here’s the gist: Andromeda was the daughter of Cepheus and Cassiopeia, king and queen of Aethiopia. Her mother boasted that she was more beautiful than the Nereids, who were the companions of Poseidon. As a punishment for Cassiopeia’s hubris, Poseidon sent a sea monster to ravage Aethiopia, and an oracle recommended to Andromeda’s parents that she be chained to a rock on the shore, where the sea monster would eventually claim her and be pacified. Fortunately for Andromeda, Perseus happened along and saved and subsequently married her. Below is one of many artistic representations of this story. gustave-moreau-perseus-and-andromeda Why do I bring this up? Well, given Andromeda is also the name of the hybrid OS due to be announced next week by Google, there are some interesting parallels. This past weekend Hiroshi Lockheimer, who owns Android and ChromeOS at Google, tweeted as follows:

Think back to September 2008, and how Android was received then. Although Google had certainly talked up the new operating system plenty, and some of the early coverage was pretty breathless too, the reality is that early Android was pretty disappointing. The hardware was clunky and ugly, and it took several years for Android smartphones to begin to approach parity with the iPhone, both in terms of performance and in terms of sales. Of course, over time Android smartphones became very competitive and eventually began to outsell iPhones significantly, but if you were to plot the trajectory, it would look something like the chart below. hubris-curve My worry with Lockheimer’s remarks is that, in September 2008, Android wasn’t obviously going to be the hit it has since become. In hindsight, the launch of Android was enormously important, and helped create today’s smartphone market, but at the time the G1 launched it was a clunky and marginal bit of hardware. The concern is that whatever Google announces next week will be received – at least initially – in the same way. Perhaps some will see in it the promise of amazing things to come, but I suspect the initial impact will be marginal, and it will take years to see the true impact. And it’s entirely possible that the impact won’t be nearly as impressive as Google clearly thinks it will be. Although Lockheimer is saying that we’ll look back on October 4th as being a milestone event, he’s saying it ahead of time, and that’s where the hubris comes in. Interestingly, the mythological Andromeda’s personal trajectory fits rather nicely onto that curve above too – her mother’s hubris has her flying high, only to be brought low by Poseidon’s wrath and her parents’ intended sacrifice of her, though eventually she’s rescued by Perseus and things start looking up again. Google’s Andromeda might well go through the same curve too – overhyped up front by company executives, only to fail to meet expectations in its early versions, though perhaps redeemed as the vision plays out over time.

Nougat Launch Highlights Android’s Slow Rollout

Google today released Android 7, codenamed Nougat. What this means in practical terms is that owners of recent Nexus devices can download and install the new version immediately, while the vast majority of Android device owners have to wait patiently for the update to be available for their device. This seems like a good time to revisit some of the stats around Android version adoption to put all this in context, because the reality is that it’ll likely be almost two years before even 50% of the base has access to the features in Nougat, while Nougat itself will likely never get above 40% penetration of the base.

For earlier posts on this topic, see:

Although those past posts have largely focused on the implications for developers, this time around I want to focus a little more on the implications for users.

Overview of Android version adoption

If you’re reading this, you’re likely familiar with how Android rollouts work, but here’s the process in brief:

  • Google finalizes and releases a new version
  • Device makers, who have had access to beta versions, work on customizing that final version to run on their various devices, incorporating their own software customizations, user interface elements, and so on
  • In the vast majority of cases, that updated software is sent to mobile carriers, who also have to spend time testing and approving the update
  • Once the device-specific version is approved by the mobile carrier, it is made available to users of that carrier.

The end result is a very slow rollout of new Android versions, when compared with, for example, Apple software releases, which are instantly available to all users everywhere on day 1, or even Microsoft’s Windows updates, which are available to consumers immediately at launch (although business users likely have to wait for their IT departments to approve and push out updates).

The history of what this process looks like in practice from a user adoption perspective is shown in the chart below:

Android Versions Overview 560px

I’ve grouped released into the major dessert-denominated categories so as to simplify things here. As you can see, there’s a clear pattern early on which morphs over time:

  • Early on (2009-2011), adoption quickly spikes to rates in the 60-70% range, falling gradually over time
  • Over time, the time to hit this milestone lengthens, but peak penetration remains similar (2012-2014)
  • More recently, peak penetration drops significantly, to around 40%, while the drop off happens more gradually too.

Let’s drill into all that a bit more. But first, a quick note on the quirks of how these versions have been released in the past. The chart below shows the gap in months between Android version releases, which has varied greatly over time:

Android Versions Months From Last Release 560pxEarly on, major new (“dessert”) releases showed up  every few months, with the C, D, and E releases following particularly quickly on each others’ heels, while the F-J releases came slightly less quickly, and the most recent releases have occurred a little either side of a year apart. It’s worth noting that the H release, which isn’t in the chart above, was for tablets only, while the I release converged the smartphone and tablet flavors, and also that the K release (KitKat) took a very long time to follow Jelly Bean, which as a result had that much more time to build a substantial base. This will be important context as we look at some of the trends below.

Peak penetration has fallen dramatically

To start with,  peak penetration rates – i.e. the maximum penetration of the Android base – have fallen dramatically with recent releases, as shown in the chart below:

Android Versions Highest Percentage 560pxThere are a couple of anomalies here, which mostly relate to the quirks of release timing and other details I just referred to. But in general it’s very clear that earlier releases hit peak penetration rates in the 60-70% range, while the two most recent releases have hit maximums of 41% and 36% respectively (Marshmallow hasn’t peaked yet).

Time to peak penetration is long

One of the reasons for the lower peak penetration rates is likely that adoption as a percentage of the base has been that much slower. The time taken to reach peak penetration has lengthened since those early days, despite the fact that peak penetration rates are lower. The chart below illustrates this:

Android Versions Months to Peak 560px

The pattern here is marred by a couple of outlier data points – notably the Gingerbread release, which took an unusually long time to reach peak penetration for an early release, and the Lollipop release, which did so quite quickly. But the trend is generally upward – early releases mostly took 10-12 months to hit their peak rates, while later releases have mostly taken 14-18 months to do so. That means releases often don’t peak until after a new version is released.

This is particularly striking right now, when Nougat is being released, but its predecessor Marshmallow is currently only the third most widespread version of Android, behind the two previous versions. The top version is actually the version from two years ago, while the next most popular version is the one from three years ago.Android Versions Ranking August 2016 560px

Put another way, the version of Android Google “released” in October last year is currently outranked by the version released in July 2012, as well as the versions released in October 2013 and November 2014. And of course that will be the case for the Nougat version too for the foreseeable future.

The user perspective – 18 months for the average user

As I mentioned up front, I’ve often focused in these analyses on the developer perspective – after all, targeting a base which is fragmented across so many different versions is tough. But Google has addressed that fragmentation at least in part over the last several years, and that path has been well trodden both by me and by others. Today, I instead want to focus on the user perspective – what does all this mean if you’re an Android user?

I think a useful way to think about this is how quickly a majority of Android users can expect to be able to experience the features and functionality in a new version of Android after it’s launched. The chart below shows how long it takes versions of Android to reach 50% penetration of the base from launch. Because recent versions have peaked before hitting 50%, I’ve included the combined total for that version and the subsequent version (which of course also offers those features):

Android Versions Months to 50pc 560px

As you can see, from the Eclair to Gingerbread releases, it took a year or less for new versions to reach 50% of the base. But the ICS release took 18 months to reach that milestone together with Jelly Bean, which itself took just a little less time to reach 50% on its own. And the KitKat and Lollipop releases took over 18 months to reach 50% of the base.

In other words, the average Android user can expect to wait over a year and a half (and probably six months from the release of the subsequent version) to be able to use the features in a new version of Android. If you factor in the months from when a new version is demoed on stage and announced at I/O or before, it could easily be two years before many users see these features.

No wonder Google appeared to de-emphasize the core features in the N release of Android at I/O this year. The core features of Android N for smartphones got just 14 minutes of stage time in the nearly 2 hour keynote – compare that to an hour for iOS at WWDC. And that makes sense if most users won’t see those features for two years.

But of course from a developer perspective it also applies to things like the VR features in the new version of Android, which also require new devices. The addressable market for Daydream on Android will be tiny for the foreseeable future – if Nougat adoption follows the path of the two previous releases, it can hope for roughly one-third penetration of the base in two years.

Operating system user bases

Related: two previous posts on the patterns in Android adoption rates (December 2013, March 2014), a post contrasting iOS and Android adoption patterns, and a post from last month on iOS 9 adoption.

Both Apple and Google have just updated their mobile OS user stats, while Microsoft shared a new number for Windows 10 adoption at its event this week, giving us a rare opportunity to make some comparisons between these major operating systems at a single point in time. We now have the following stats straight from the sources:

  • The stats provided by both Apple and Google on their developer sites with regard to the user distribution across their mobile operating systems (Android and iOS)
  • The 110 million Windows 10 number provided by Microsoft this week
  • The 1.4 billion total active Android user base number provided by Google at its event last week
  • Total Windows users of around 1.5 billion, as reported by Microsoft several times at recent events.

In addition, there are various third party sources for additional data, including NetMarketShare and its estimate of the usage of other versions of Windows. Lastly, I have estimated that there are roughly 500 million iPhones in use now, and around 775 million iOS devices in use in total (including iPads and iPod Touches).

If we take all these data sets together, it’s possible to arrive at a reasonably good estimate for the actual global user bases of major operating system versions at the present time. The chart below shows the result of this analysis:User bases all iOSThere are several things worth noting here:

  • Each company has one entry in the top three, with Microsoft first, Google second, and Apple third.
  • However, only one of these entrants is the latest version of that company’s operating system (iOS 9), while the other two are the third most recent versions (Windows 7 and Android KitKat).
  • Google has three of the top six operating systems, none of which is its latest operating system (Marshmallow, released this past week). Even its second most recent version (Lollipop), now available for a year, is only the third most adopted version after KitKat and Jelly Bean.
  • Both iOS 9 and iOS 8 and the three most used versions of Android beat out every version of Windows but Windows 7.
  • The most recent versions of the three companies’ major operating systems are used by a little over 400 million (iOS 9), 110 million (Windows 10), and a negligible number (Android Marshmallow) respectively.
  • The second most recent versions are used by around 330 million (Android Lollipop), around 250 million (iOS 8), and around 200 million (Windows 8) respectively.

There are lots more data points to tease out here, but to my mind it’s a striking illustration of the differences in the size and adoption rates of these three major operating systems.

Two additional thoughts

Just for interest, I’m including a couple of additional thoughts below.

First off, here’s the same chart, but with iOS reduced to just the iPhone base. The order changes a fair amount, but iOS 8 and iOS 9 still make a good showing:

User bases based on iPhone onlyLastly, I wanted to revisit my post from a couple of weeks ago about the initial adoption of iOS 9, especially as it relates to Mixpanel’s data. In that post, I showed how Mixpanel’s iOS adoption data tends to be pretty close to Apple’s own data except for the month or so after a new version of iOS ships, when it tends to skew way lower than Apple’s own data. Now that we’re a few weeks on from the initial launch, and Apple has released the second set of iOS adoption data since the launch, I wanted to revisit that pattern. Interestingly, the very same pattern is playing out again – despite the initial significant discrepancy, Mixpanel’s data is now once again very close to Apple’s own:Mixpanel iOS data October 2015

iOS 9 adoption and Mixpanel

Related: Apple Topic Page, and a previous post on iOS and Android adoption patterns, as well as two earlier posts (1, 2) on Android versions in use.

Last week, following the release of iOS 9 by Apple, Mixpanel (along with other analytics firms) began releasing data relating to the pace of adoption of iOS 9. That data suggested that iOS 9 was being adopted more rapidly than iOS 8, and also that it had reached around 30% by the end of the day on Saturday. Then, this morning, Apple issued a press release about the new iPhones, but in passing noted that iOS 9 was now on more than 50% of devices, based on data from Saturday, September 19th. That’s a fairly sizable discrepancy, and it made me want to dig into the numbers to understand what was going  on.

Note: I’ve reached out to both Mixpanel and Apple about this, and I will update this post as warranted once I hear back from them. As of right now, the analysis below doesn’t include any additional information from them beyond what they’ve put out publicly.

A word on methodologies

It’s worth starting with a quick statement of methodologies. Apple’s goal is to give developers a sense of the operating system versions their target audience is using, and so is based on devices hitting the iOS App Store (Google, incidentally, does the same thing). It generally seems to pick a specific single day, usually a Monday, and measures which versions of iOS those devices hitting the App Store are using.

Mixpanel, on the other hand, provides analytics to app developers to help them understand engagement around their apps, but in the process also collects lots of data on which operating systems the users of those apps are running. As with any analytics software of this kind, the picture will always be incomplete, but the bigger the base of devices, the more likely it is to be representative, and Mixpanel’s is fairly big at this point.

Mixpanel is generally very close from October to August

With that note on methodologies as context, the first thing to note is that Mixpanel is generally very good at approximating Apple’s own numbers for iOS adoption, even though their methodologies are different. For the period from October 2014 to August 2015, Mixpanel’s numbers generally tracked within about 4% of Apple’s own numbers for iOS 7 and iOS 8 adoption. Interestingly, Mixpanel tends to estimate higher usage for the latest version and lower usage for previous versions than Apple.

September seems to be more of a problem

However, even though Mixpanel’s data tracks closely to Apple’s for most of the year, it tends to be quite a bit off the mark in September, immediately after the release of new iOS versions, at least for the last two years. The chart below shows the difference between Apple and Mixpanel’s adoption rates for iOS 7, 8, and 9. Negative numbers mean that Mixpanel’s rate is lower than Apple’s, while positive percentages mean Mixpanel’s numbers are higher.Mixpanel and Apple iOS adoption rate differencesThe chart shows several things that are worth noting:

  • As I mentioned, the margin of “error” (I’ll explain the quote marks later) is generally under 5%, though as you can see it grows steadily from late October 2014 to September 2015
  • However, the discrepancy between the two figures is much more significant for two dates – September 21, 2014, and September 19, 2015 – which happen to be the dates immediately after the launches of the new versions for the last two years. In both cases, Mixpanel’s adoption rate for the new version of iOS was far lower than Apple’s, in contrast to the usual pattern during the year.
  • The discrepancy quickly shrank last year – by early October the two numbers were very close again. We don’t know yet what will happen this year, of course.

What explains the September discrepancy?

I’ve carefully avoided describing Mixpanel’s data as faulty above – I did use the term margin of error once, but carefully put “error” in quotation marks. And that’s because even Apple’s own numbers aren’t necessarily accurate in reflecting the devices actually in use. For the sake of developers, knowing what mix of devices hit the App Store is of course actually more important and relevant than knowing the total mix of devices out there. But it’s not necessarily an accurate picture of what people are using across the broad base of devices. Mixpanel’s data may actually be more representative of the actual base of devices in use, but there’s no way to know for sure; ultimately, it is also measuring something other than true adoption rates across the base.

So, having framed this as a discrepancy or difference rather than an error, what explains why the numbers are so close from October to August, and yet so far apart immediately after a new iOS version launches? Here are a few possibilities:

  • Apple’s numbers, which reflect App Store visits, are unduly skewed early on by the influx of recent updaters looking for apps that take advantage of new features – e.g. content blockers, multitasking, and in-app search in iOS 9. Once the initial rush has subsided, App Store visitors return to looking more like the overall base. Since we don’t have detailed day-by-day data from Apple, it’s hard to tell how quickly this effect wears off, but I suspect it may be a big part of the answer.
  • It’s possible that Apple’s numbers, which are global in nature, are more representative of true trends than Mixpanel’s, which may skew towards (or away from) particular countries. As a result, if users in China or other major markets which Mixpanel may not track as closely update iOS more quickly, Apple’s numbers might capture that whereas Mixpanel’s wouldn’t. As download rates catch up in other regions, the discrepancy would work its way through over time. I don’t know enough about Mixpanel’s data to know how much of an issue this is, but it might be a secondary factor.
  • Apple’s regular iOS adoption data is usually captured on a Monday, whereas its post-launch data for the last two years was captured at the weekend (a Sunday last year, and a Saturday this year). It’s possible that the mix of devices in use – and especially those hitting the App Store – on the weekend is different from those in use on a Monday, but this is unlikely to account for much of the discrepancy, especially since the Mixpanel data was collected on the same day.

Another thing that’s worth noting is that other sources of iOS adoption data tend to agree more with Mixpanel at this point than with Apple’s numbers – both Fiksu and David Smith’s Audiobook app data tend to suggest adoption closer to Mixpanel’s than Apple’s, for example. So, either all these methods suffer from the same “problem” or Apple’s data is actually unrepresentative of the true base of devices out there, especially in these first few weeks. Until I hear more from either company, it’s going to be hard to know which is the case. But it’s certainly worth viewing Mixpanel’s data (and any other third-party data) in this context in the future, especially when it comes to the period immediately after a new version of iOS comes out.

Apple’s Playbook

One of the most interesting slides at yesterday’s Apple event was one that Tim Cook used in the context of introducing the new Apple TV:Apple PlaybookWhat I found striking about this slide was that it was a great summation of Apple’s playbook for its tightly integrated approach to hardware and software:

  • Powerful Hardware
  • Modern OS
  • New User Experience
  • Developer Tools
  • App Store.

This playbook was first introduced with the iPhone, although arguably it wasn’t fully fleshed out until 2008, when the developer tools and App Store elements arrived. This approach was then applied again both to the iPod Touch when that launched, and when the iPad launched in early 2010, using the same “modern OS” – now called iOS. Later in 2010, Apple began applying some of these elements back to the Mac (announcing these changes at an event called “Back to the Mac”), starting with the Mac App Store, and continuing since then with a variety of elements borrowed from iOS.

With this as background, it’s no surprise that Apple felt bound to include an App Store in the first version of the Apple Watch, but out of an abundance of caution and a sense of urgency, it was a diluted version of the App Store concept. Only with the launch of WatchOS 2 this month will Apple fully embrace its own playbook for devices when it comes to the Apple Watch. And as of yesterday, we now know that Apple is applying this same playbook to the Apple TV too, something that’s seemed inevitable for quite some time now.

With the release of WatchOS and the announcement of the new Apple TV, Apple now has the same strategy for hardware and operating systems for every element of its portfolio for the first time. The question now becomes which new categories Apple might apply this strategy to in future, and one obvious possibility is cars. Look at that list of bullet points that make up the Apple playbook – is there any element of this that doesn’t apply to cars?

The other thing that’s interesting about all this is that this strategy puts developers at the heart of Apple’s formula for success. Three of the bullet points are about what Apple brings to the table for end users – the hardware, the software, and the user experience these two elements tightly integrated create. The fourth and fifth bullet points are about what Apple provides for developers – the tools to create the apps, and the channel to get these apps in front of customers and make money from them. I think this is a reflection of a genuine understanding on Apple’s part that its devices would be far less meaningful without these third party apps.

Given what’s happening now with Apple Watch and Apple TV, I’m expecting to see a ton of innovation from developers in creating new experiences that are hard to imagine today. We’re about to see the same sort of flourishing of new apps and business models around these devices that we’ve already seen around the iPhone and iPad. And that in turn will reinforce the value of these devices for end users, while creating significant new revenue opportunities for developers.