Mobile Picking Good Clients by Android OS
With Android N (Nutella? Nougat? Nestle? Or, my favourite, Naan) coming out this summer, there will be at least 5 significant Android OS flavours out in the field (and even more API versions) that need to be supported. Let’s all call it for what it is. A giant pain in the ass.
Taking a look at this Google Dashboard of Android versions (as of today, updated on June 6th, 2016), there are 10 API versions which currently register. Throwing away the oldest 3 still gives us 95% coverage of Android devices, which is great. Here’s where things go off the rails…
Jelly Bean (API 16, 17, 18) comes in at almost 19%! That means, 1 in 5 Android devices runs an OS that was released almost 4 years ago. In mobile timelines, that’s ancient! May as well be carving pictures in walls with sticks.
Kitkat comes in at a whopping 30% of the market, having been released near the end of 2013. This one is a bit more understandable, because cell phone plans are in the 2-3 year range generally, and when those plans are renewed, new cell phones are purchased - so I’d anticipate that number to drop drastically over the next 6 months.
One Of The Few Things I Like About Apple
The crazy part about this whole OS debacle is that the two most recent OS flavours (Lollipop and Marshmallow) don’t even account for 50% of the phones in the market, and Lollipop is almost TWO YEARS OLD!
Compare this to iOS, using this site as a rough barometer, iOS 9.x is registering close to 90%! It was released less than a year ago! Within a week of release, they had 50% adoption… iOS 7 and 8 make up most of the remaining 10%.
There are two main reasons for this… First, Apple controls the hardware AND software of their products, to ensure compatibility across versions
- meaning they don’t have to worry about random manufacturer X making a phone which can’t run iOS 10 or whatever. Secondly, Apple’s ‘forced’ updates. They’re not quite forced, but they nag you every day, and Apple deprecates APIs and functionalities much, much faster than Android.
Google has a harder time playing the forced update card, because of all the manufacturers they have to wrangle up, and each cell phone carrier gets to roll updates on their own (which is garbage). So, we have to wait until a carrier makes all their desired tweaks to the OS, and then hopefully they give us the privilege of downloading the update in a ‘reasonable’ 6-12 month timeframe.
And before anyone says “but you can update the OS yourself using Cyanogen!”… Yes, true, -I- can update the OS myself. Not a problem. About 90% of the people I know can’t do that, they would be completely lost. And the only reason it’s as high as 90% is because I mostly surround myself with nerds.
What About Android N?
Well, Android N will be another great update to the platform, but what will the adoption be? Maybe, if we get lucky, within a couple of months it will rise right up to 45%! But, here’s the thing… It’ll be the 45% of people who are already using Lollipop and Marshmallow, which are the two most stable Android platforms anyways.
Jelly Bean and KitKat users have been abandoned until they get new phones. And until then (again, hopefully within the next 6 months) - we’re stuck with them.
Why Do I Care?
Most of the time, I really couldn’t care less about what phone someone has, or what OS they’re using… However, my clients care - and they care a lot.
Supporting Android OS versions dating back 4 years and some 10 API versions is hard enough on it’s own but do-able. Performing QA on all these versions and manufacturers is getting exponential (automation can help, which I’ll be writing about in upcoming posts).
As readers of my blog know, I do a LOT of Bluetooth Low Energy work. On iOS, that’s not much of a problem… However, on Android, BLE support can range from terrible to absolutely horrific. And the (not so) dirty little secret? BLE support is worse in older OS versions.
I consider Lollipop to be the line in the sand when it comes to Android BLE support. Lollipop was such a huge step forward, that I struggle to even justify working on pre-Lollipop BLE projects… Then I look at that damned dashboard and see that if I don’t support pre-Lollipop, I’m losing at least 50% market share.
The next line in the sand is Jelly Bean vs KitKat. I’d say that Android BLE support was introduced in API 18, but it was ‘really’ introduced in API 19. API 18 feels more like someone forgot to ‘ifdef’ out the BLE test code and Google just ran with it.
Jelly Bean BLE support is on the ‘absolutely horrific’ side of things. It doesn’t adhere to the BLE standard, causes all kinds of problems across manufacturers, and is just generally BAD.
What Good Clients Do?
Now, all that ranting aside, the objective of this post is to understand how to pick good clients based on their Android OS versions. Specifically, their OS requirements for building an app.
When I meet a client who continues to say (after a back-and-forth with me) “we need to support all Android devices in the field”, I run away. This is a client who has no idea what that entails, what this requires from a dev/QA perspective, and how bat-shit crazy this is. Most importantly, to me, this is a client who doesn’t have a good feeling for diminishing returns, or return on investment.
A common retort I get about this is “What do you care? You’ll get more money”. Absolutely… But that’s not the goal of a consultant/client relationship. The goal is mutual benefit and continued success. I’m less interested in padding my pockets, than I am in seeing a product make it into the field. THAT is the reward I go for. Money follows success, not the other way around.
A ‘good’ client would listen to reason, and when they hear something like “We’re going to spend the same amount of money to dev/QA for 50% of the market, as we will for 5% of the market”, and immediately want to drop support for that 5% of the market. Or maybe offer that 5% a subset of their product. Or at least re-think their strategy based on that new information.
What Should You Do?
I can’t say that there is NEVER a reason to build something for the entire Android market, but I can safely say that in the vast majority of cases, there is no reason to pander to everyone. Unless you’re Google writing a new Support library, in which case, you need to do something like that by definition.
Think about the future, as well as the present
For example, I’m releasing a BLE app into today’s market, I know that I probably need to test/support KitKat devices because there are so many (30%). But what if I was starting that same app now, planning to release in 1 year? I’d probably ditch pre-Lollipop support, knowing that segment won’t get bigger, and given the cell phone lifecycle, it’s due for a drastic cut.
Put costs into perspective
As I said above, I’m probably spending the same amount of money to QA Lollipop, as I am to QA Ice Cream Sandwich (keeping in mind that for each OS version, you should be testing multiple devices)… So, knowing that, bringing up a cost per user, or a cost per percent market share is a great metric to show value (or lack thereof).
Pick a rule and stick to it when you can
My rule of thumb is based on years and percentages. If it’s less than 10% of the market, and older than 3 years - drop support for it. That’s probably why most of my apps support API 19 and up!
P.S. What Kicked This Off?
So, I wrote this whole thing based on this week’s experiences, where several of my clients finally decided (all in the same week) to drop Jelly Bean support from their requirements for new apps. I was over the moon!
P.P.S. Wiping the App Programmatically
So programmers don’t leave empty handed, here is the reason that a conversation about dropping Jelly Bean support came up (all because of those stupid @TargetApi annotations or Build versions):
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
((ActivityManager) getSystemService(Context.ACTIVITY_SERVICE)).clearApplicationUserData();
} else {
// TODO: Some depressing code
}