Contrasting iOS and Android adoption patterns

I’ve done two previous posts (here and here) on Google’s Android developer dashboard stats, and I was surprised to find it’s been just over a year since my last one. I may still do a deeper dive revisiting some of the points from those previous posts, but this time around I wanted to do something different – contrast Android and iOS adoption patterns. Google has published data on Android version adoption for quite some time now, but Apple’s only been doing it for the last couple of years, so we have less data. But we still have enough from both platforms that we can draw some interesting conclusions.

iOS adoption – huge initial ramp plus slow conversion

The pattern for iOS adoption is very clear – a massive initial ramp in adoption in the first few days and weeks, followed by a steady conversion over time. The chart below shows the share of the base on each version in the first 24 months from launch:

As you can see, by the time the first month is over, more than 50% of the base is already on the new version, and it ramps to around 90-95% by a year later, just before the next version launches. At that point, it immediately drops to 25-30% as the new version takes over, and slowly dwindles from there down to under 10% after two years. There are differences in adoption rates for the various versions shown – as has been reported, iOS 8 has seen a slower initial adoption rate than iOS 7, though it’s now over 75%. Correspondingly, the share of iOS 7 has fallen slightly more slowly than iOS 6 did, though the gap in both cases has closed a bit recently.

Android adoption – an 18-month slog to significant adoption

By contrast, Android gets off to a much slower start, due to the multi-stage cycle of version releases, work by OEMs, carrier approvals and so on. A similar chart for four recent Android versions is shown in the chart below (I’ve grouped point releases into their dessert flavors, as it were):

iOS hits 50% adoption within the first month, but Android can take over a year to hit 50%, and of the three longer-running versions shown here, only one ever got over 50%. The other interesting thing is that Android versions tend not to peak or hit majority adoption until after a new version has been released. KitKat, for example, just barely became the most used version of Android this month, about six months after Lollipop launched.

Here’s a chart that shows peak adoption rates for three flavors of iOS and Android (bear in mind that iOS 8 is likely about 5 months from its peak, which will occur just before iOS 9 lands in September, and that KitKat also hasn’t peaked yet, but I’m estimating that it will do so shortly at around 43%):

Developer strategies

Now, the reason Apple and Google post this data is to assist developers in deciding which versions of the respective operating systems to target. So what conclusions can we draw from all this as to the best strategies for developers of iOS and Android apps?

Supporting a single version

This strategy wouldn’t serve most developers on either platform very well – it would work better on iOS, where the majority is consistently on a single version of the OS, but even there much of the base would be inaccessible. On Android, this strategy would be disastrous, as single versions rarely get above 50%:

Certainly, the strategy would be more effective on iOS than on Android, because share is consistently significantly higher, but this seems a poor strategy on both platforms. If we make a slight change and now focus on supporting the latest version, things get even worse for Android:

This strategy is obviously completely unworkable for Android, because the most recent version rarely gets above 25% before a new version is released. And supporting a single version, but an older one, is also impractical, since the most attractive users will often be those who upgrade earliest in the cycle.

Support two versions

On iOS, supporting two versions would be an entirely realistic strategy, since the top two versions tend to command an overwhelming share of the base. On Android, too, this would make a big difference, but once again, not as well as on iOS:

Targeting the top two versions of Android captures around 75% or more of the base pretty consistently, but on iOS it captures over 90% of the base and later in the cycle close to 100% of it. Again, though, on Android targeting the top two versions typically doesn’t mean targeting the two most recent versions. That strategy wouldn’t work nearly as well:For iOS developers, however, supporting the two most recent versions is an entirely workable strategy.

Other strategies for Android

The biggest challenge with Android is not just the sheer number of versions that command significant share, but that the newest versions take quite so long to achieve meaningful share. As such, developers who invest in supporting the newest version right away may not see much return on that investment for months at best. However, again, those early upgraders may well be among the most attractive customers because they’re likely committed to the platform and eager to try new things. Leaving them out becauseof their small size probably isn’t the best strategy either. Ultimately, if Android developers want to target 75% or more of the base, they have to support more than two versions, and often four, especially if they want to target new versions immediately. Supporting the last three years’ versions is one way to consistently target 75% or more of the base. But bear in mind, too, that we’ve clustered point releases together in all this analysis: in reality, there are three different versions of Jelly Bean (4.1-4.3) and there are already two versions of Lollipop (5.0 and 5.1), all of which would be included if you were aiming to support the last three year’s releases today.

iOS First still makes a lot of sense

There’s simply no getting around it: developing for Android requires support for significantly more versions, on top of all the other complications like many different screen resolutions and sizes. And we haven’t even discussed the return on investment from targeting a single user or percentage point share of Android versus doing the same on iOS, another area where Android becomes less attractive to develop for. Is it any wonder, then, that major apps (including recent examples Meerkat and Periscope) still target iOS first?

A blog about consumer technology from Jackdaw Research

Casper

First of all: https://developer.android.com/google/play-services/index.html

Second point; in android there is a difference between targeting and supporting a version: https://developer.android.com/tools/support-library/features.html

Third point: Many cross-platform makers point too different but similar in scope problems with developing for different platforms e.g. http://blog.shiftyjelly.com/2013/08/01/ios-vs-android-great-balls-of-fire/

Fourth and last point – Meerkat and Periscope are bad examples as they are both video-apps and that exact feature seems harder on Android – see Hyperlapse fra Instagram. There is a lot of reason to develop first for the iPhone(and as a start-up you should!), but its not the complexity of building the app (given its not a video app).
- Rob LaPointe
  
  I agree with you at the fourth point well said, Meerkat and periscope are video live streaming apps, the features seems not suitable at all fro android. Also Its always good to start with iOS and shift to cross platforms its because portability in code is easy iOS >> Android > Web apps http://goo.gl/Fkqza
- Jan Dawson
  
  I used those two because they are the most recent popular apps to land on smartphones. But the same would be true if you look at almost any other major app – it launches on iOS first, at least in part because it’s much simpler to support a wide range of devices on iOS. (see also http://www.beyonddevic.es/2014/12/05/the-windows-phone-app-gap/ – the “time gap” section)
obarthelemy

For Android, you seem to be assuming each app needs to be written to a specific version of Android, which isn’t the case: newer Android versions are backwards-compatible; and for most new functionality, libs are even supplied to also make older versions forwards-compatible (by substituiting library code for stuff the older OS doesn’t implement). There’s no chart describing that ?
In Android, you don’t write apps to a version, you write them to a version *range*.
- Jan Dawson
  
  There’s always this argument about cross-platform development too: that some of the tools available today allow you to build things that “work” across different platforms. In my experience, an app “working” on a particular platform (or version of the OS) is not the same as being optimized for it, and I think the same applies here. Yes, technically, you can ensure that nothing in your app breaks by using such an approach, but if you want your app to both look and feel right on any given OS version you choose to support, and enable all the relevant features in that version, you have to go beyond this basic approach.
  - obarthelemy
    
    How have you come to thinking this ? Truthiness ?
    Have you ever actually written an app ? Do you have specific examples of apps that got better when ditching cross-version, or worse when going cross version or widening the cross ?
    Or is it just a.. gut feeling… with no factual/empirical grounding whatsoever ?
    
    I’m asking because I find your comparison between cross-version and cross-platform extremely iffy:
    – to start with, Android is not so much about “versions” as about API levels,
    – then, cross-version on an evolving OS and cross-platform on unrelated OSes are two very different scenarios
    – then, Android’s versions are not the same thing as iOS’s versions, because Android is modular (Google Play Services evolve with no connection to the underlying OS for example)
    – and Android specifically supports cross-version development and target+compatible API levels for each app.
    
    There are certainly some cases when “OS versions” does make a huge difference, but for the huge majority of apps, they don’t. I’ve got devices from 4.0 to 5.0 (that’s late 2011 to current). All run the same apps, the same way, I can’t possibly tell if apps were written to a specific version nor which version.
    - Jan Dawson
      
      Keep it civil, please.
      
      This is the industry I spend all day every day researching and analyzing, and I speak to lots of developers. I don’t develop apps myself. I’ve seen lots of examples of the kind of thing I’m talking about here, which is why I’m talking about it. With regard to cross-platform development, I’ve absolutely seen apps which were either clearly developed for one OS with no attempt to change the UI and design for another OS, or which were designed using generic tools and therefore don’t look at home (i.e. don’t follow UI conventions) for any of the platforms on which they run.
      
      Android versions map directly API levels. 4.4 = 19, 5.0 = 20, 5.1 = 22, for example. As such, I’m not sure what your point is.
      
      The two are different scenarios, but share the characteristics I mentioned. They’re analogous, but not the same.
      
      With Android, some key differences between versions include the way menus are handled (embedded vs. virtual buttons etc.). Those have changed significantly over the last several years, and I often come across apps which were clearly designed with one or the other in mind but therefore don’t work so well on either older or newer devices.
Walt French

Ultimately, the question of which versions a developer supports depends on how much that app depends on features that are only available in the OS, maybe a bit of how design themes agree.

Many Android features are reportedly available independently of the base OS, and of course, most apps do not need the majority of features that a new OS brings, anyway. The ability of an app to use an OS feature if it’s available, and have some lesser function otherwise, also allows support for mixed OS versions.

There’ve been some dramatic changes in iOS appearance lately; it’d be hard to have your app look “good” if it tries to be compatible with the old look. But that’s a far cry from working well, unless the user gets confused by a mixed UX.

So while it may be some extra work, mostly this is a thing that iOS and Android developers BOTH deal with. It seems far from as black-and-white as presented here. How about a more nuanced look?
- Jan Dawson
  
  I hope this doesn’t appear too black and white – the final section talks about the other factors that developers also have to take into account. But multi-version support is still an issue despite the abstraction of certain Play Services elements from the OS.
  
  Looks-wise, since the major change in design occurred in iOS 7, supporting the most recent two versions on iOS wouldn’t cause any problems, since both recent versions have the new, “flat” look. Android, of course, has also been changing, but more subtly over time, with Material Design the biggest change, but one that’s effectively been underway for some time.
  
  Regardless, a key issue with regard to iOS vs. Android development remains that with iOS you can support two recent versions of the OS and a specific, small number of devices (with the exact number depending on whether you are developing iPhone-only or iPhone/iPad apps) with known resolutions and specs and cover the vast majority of the current base. Not so on Android. What I’ve presented here is only part of this picture, but an important one.
Emmanuel Pont

Sorry for adding one more comment about Android versions, but in practice nowadays the version compatibility is pretty easy if you develop for 4.0+ (except for some rare and very specific features that were added later). Problems arise when developping for 2.3+, and there are still serious headaches from manufacturers buggy implementations.